A Conflict Exists For -<module Name> while updating Record

IN suitecrm, While updating record in custom module, after clicking on save this page arrives

It shows different format for date
Yours----> Date format yyyy-mm-dd hh:mm:ss
in Database—>>> format mm/dd/yyyy hh:mm

I ma using MSSQL server. and date format is yyyy-mm-dd hh:mm:ss. check image

I have set timezone- (GMT-4) but for (GMT+0) also, its showing same page after save.

suitecrm - Version 7.11.8

Experts, please provide some solution if any one can.
Thank you in advance.


Do you get this issue on every save in this custom module? If so, is it on other records in this module?

Does this happen in any other modules? (custom or core)

I believe this screen normally would appear if the data differs in the database from when the record was initially loaded, typically if multiple users/systems are modifying this record at the same time

Do you know if its possible if another user/system was perhaps changing this record at the same time?

I’m pretty certain that this means that you have a UUID conflict - so either:
a. Congratulations - go and buy some lottery tickets as this is an extremely improbable occurrence. If you do win the jackpot, I’ll be happy to help you spend it :smiley:
b. Your custom module has an error in the way that it creates the UUID leading to duplicates.
c. Your custom module in some way seeds the UUID based on the data it receives. In this case, it means that the UUID seeding process has created a conflict…which assuming that the seeding is sensible, implies that you’re trying to enter in something that is as pretty much a duplicate.

1 Like

Thank you for your response and time.
Issue exists on particular module only.
no concurrent users using this.

Thank you for your response and time. I must say you have great sense of humour. :smiley:
How can I check this UUID condition? Where I can check all this you have mentioned?
also is there any way I can check queries hitting database.
P.S. I have checked suitecrm logs too. But no log over there .

In order to check for a UUID issue (and whether you should gamble your life savings on the National Lottery), you will need to look at the table schema concerned. There will be something called a primary key, or some other field designated as a key that is identical and causing the conflict. Check that the record really is the same one. I’m inclined to think that it is based on the Date of Birth being the same (although differently formated)

The alternative is that this is a bug in the module, and it is required to have the data/time presented in a specific way. (Try mixing suiteCRM extensions designed in USA with those designed in Europe if you want to loose hair). If this is the issue, you may be able to mitigate the bug by changing your date/time format to mm/dd/yyyy - The conflict comparison could potentially be presenting the information in it’s own internal date format with that presented by suiteCRM. (I’m going to make a guess here that Date of Birth is the key causing issues here?..and what you want is to force the suiteCRM presentation to match) This is one of the delights of date formats! 06/06/2020 is understandable, 06/23/2020 is understandable, but 06/09/2020 is not understandable without context if the data is stored as a string (rather than a date).

In order to change the date presentation and retry, select profile, then advanced and change your date format to match. (BTW - If this works, still raise this as a bug with the module provider!)

With respect to logging, by default you’ll probably not see that much. This is because the logger by default is set to minimum level of ‘error’. You can increase your logging level to see more information - BE AWARE THAT THIS CAN QUICKLY BECOME GB of logs, so make sure that you have the disk space before you do it, and keep monitoring you spare drive space. Don’t forget to change this back when you’ve finished! Changing the logging level can be done in Admin->System Settings->Log Level

Further information can be found:

I have found the solution . It is happening because optimistic_locking (module//vardefs.php.) property was true. We set it to false and it gets resolved.
for more info- check here- https://docs.suitecrm.com/developer/vardefs/

Thank you all, for your time and feedbacks. It was indeed valuable.

1 Like