11-05-2010 01:09 PM
We had this problem creep up again for a client....
Resolution Details
TITLE :
Defect - Error: "Row cannot be located for updating. Some values may have been changed since it was last read." Editing database records with date values set around the DST change-over time
DETAILS :
Existing Defect ID: N/A
Related Defect ID: 1-38000
Case Number:4492325
SalesLogix Version: Build Number: 7.5.2
Database Platform: VersionQL05
Mobile Version: Mobile Database Version: Mobile Hot Fixes:
Mobile Application: Mobile Platform:
Issue reproduced (Yes or No): Yes
Issue applies to LAN, Web or both: LAN
Steps to duplicate the issue:
Work Around: Manually edit the date(s) on the record and change the the value to 3/14/2010 12:00:00PM. This will allow SalesLogix to properly adjust the date value for GMT.
11-05-2010 02:52 PM
Yes!... There is a "Gap" (Bermuda Triangle ;-) in the SalesLogix system where you do not want to be scheduling or have items scheduled that fall into either the spring or fall TZ switchover.
This weekend (at least in the USA) this "gap" is going to open again and you will have issues if you have things scheduled....
This is for all versions/SP levels of SalesLogix since the system went TZ/DST aware right thru the current 7.5.3.
Thanks for the reminder Ron!
11-30-2010 05:33 PM
What's being done on the SalesLogix end to address this?
Since the recent DST changeover (11/7/2010), we've run into multiple customer issues, where records could not be updated. In one scenario, existing records modified on a data form do not retain the changes. The other scenario involved coded update routines failing, with the error message "row cannot be located for updating. Some values may have changed..."
In each case, a good deal of troubleshooting time was required in order to identify the issue as the known SalesLogix DST bug. In each case, the customer was billed for the time spent. Given this is a known issue, that's not new, that doesn't seem right.
Is SalesLogix actively working on a resolution to this issue? I know we faced some of the same last DST change.
11-08-2013 09:42 AM
Just had this in 7.5.3 LAN.....
11-08-2013 09:47 AM
Fix is to issue a SQL command to affected table(s), updating MODIFYDATE value of all records carrying the DST date to some other value.