Usage of other primary keys than SugarCRM GUIFD

RE: Usage of other primary keys than SugarCRM GUIFD

Michael Malich — Tue, 19 Apr 2022 15:40:18 GMT

Hi Rafael,

thanks a lot for your reply and I will check the "sync key" functionality you mentioned.
But it looks like it "only" updates records and can't be used for what I'm looking for.
But seems to be very helpful for interfaces.

But I'm not talking about an interface. I'm talking about a one time data migration.
All the tables I'm migrating have relations with others and have foreign keys for these relations.
As soon as I do not use the PK of these records as the ID in SugarCRM, I have to read for example the ID of an account before I import the contacts belonging to that account. Because I don't know the ID SugarCRM has created for the account.
This has to be done for every One2Many relation and for each Many2Many relations too.
Feels like a big overhead for migrating an application into SugarCRM.

Also regarding the usage of the GUID I would like to show you what is written in the Sugar Developer Documentation.

https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_10.0/Data_Framework/Database/

There is described that it is possible to use other PK formats and the GUID is not mandatory.
There is also described what's important to use a different format.

I'm new to SugarCRM and I appreciate recommendations but I can't imagine why using a different UNIQUE key should ever make any problems. I've migrated databases into other CRMs in the past and had never problems like this. Only if you don't take care and have maybe ID conflicts in the future.

Sorry for the detailed reply, but I would like to really understand it in best case based on real problems you heard about.

Thanks
Michael

RE: Usage of other primary keys than SugarCRM GUIFD

Rafael Fernandes — Tue, 19 Apr 2022 13:24:02 GMT

Hi Michael Malich,

I wouldn't recommend updating PKs other than our out-of-the-box structure, you might run into issues on upgrades, addons and any other Sugar code that might rely on that GUID structure, in other words, try to avoid this approach.

We do, however, have a mechanism built for this type of scenarios which is to use "sync_key" to sync up your data from external (old system) to Sugar. We use it internally for our integration purposes and that's our recommended approach to you.

"sync_key" field is available on every single Sugar module and is used to:

- Speed up integrations (our recommended approach for upserts into sugar)

- Retrieve your "external system" record by using it's own ID.

Give it a shot and let us know.

RE: Usage of other primary keys than SugarCRM GUIFD

Michael Malich — Tue, 19 Apr 2022 11:20:47 GMT

Hi Jeroen,
Thanks a lot for your reply. I'm happy to hear that I'm not the only one with that opion :-)

We already have a customized field with the old legacy_id for each record.
This first data migration doesn't contain a lot of data from only a few tables.
I've used the GUI interface import and used for example for contacts the company name to link a contact One2Many. That works well as long as you have no Many2Many links. But we have that between Opps and Contacts.
So I used the Sugar API to read the necessary data and to import the Many2many link. That works well but it's a lot of additional work one can save by using legacy IDs as SugarCRM IDs.

RE: Usage of other primary keys than SugarCRM GUIFD

Jeroen Somhorst — Tue, 19 Apr 2022 10:36:27 GMT

Hi Michael,

from a technical standpoint, and my experience as a SugarCRM developer, there is no issue with using any other format as a PK as long as it is unique. As you already said yourself the only thing you need to be sure of is that the custom format doesn't conflict in any way with the default Guid format in Sugar. And as long as that isn't the case there is no issue. Sugar doesn't really care about the format in my experience.

But if you had the chance of importing the data again and without using the custom format as PK I would try to do so. To be able to find the data based on the old pk's you could add a extra field to store this value.