DST Warning

[RFisher]

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:

1. Find an Activity, Lead, Opportunity, or other database record with CreateDate, ModifyDate, OriginalDate, NeededDate, etc. that is between 3/13/2010 10:00:00PM to 3/14/2010 1:59:59AM
2. Edit the record, adding notes or making some other edit.
3. Try to save the edit
   1. It will error

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.

[RJLedger]

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!

[tedurquhart]

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.

[RJSamp]

Just had this in 7.5.3 LAN.....

[tedurquhart]

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.