3

According to here Sugar CRM uses GUIDs for PK and FK needs

By default, Sugar uses globally unique identification values (GUIDs) for primary keys for all database records

However they're not true GUIDs, at least in the sense defined here, as in debugging an issue I got a parsing error (via JSON.NET as it happens, but the same issue would be easily replicable myself)

The offending pseudo-GUID was "7f09zz7d-889a-1x19-825b-54s954665005" which is most certainly not correct.

Looking at the database table, the field that is holding this record is a VARCHAR(36), not a UNIQUEIDENTIFIER. This means that any 36 characters can be plonked in there. So far, so good - for Sugar CRM that is.

The issue arises when you try to use this "GUID" from a .NET perspective (e.g. Guid.Parse()) or SQL Server using a field actually properly defined as a UNIQUEIDENTIFIER.

This leads to two problems really:

  1. How can I make Sugar CRM generate compliant GUIDs? Bearing in mind I learned how to spell PHP about 5 minutes before typing this question. PHP appears to have a com_create_guid function but I don't know if (or where) Sugar is using it

  2. Can anyone recommend a strategy for the existing values that may not conform? Adding a nullable UNIQUEIDENTIFIER column and inserting the values from the existing VARCHAR column and handling the exceptions on a case-by-case basis is about the only way I can think of dealing with it.

noonand
  • 2,763
  • 4
  • 26
  • 51
  • 1
    In Sugar 6 you could enter whatever in the ID column, so the backwards compatibility of a VARCHAR column in Sugar 7 is at least necessary there, since they can't all be assumed GUIDs – random Sep 04 '16 at 00:19

0 Answers0