This is only happening with a small group of accounts, but when a user edits address information an account, they receive the following error:

"Could not post date

Row cannot be located for updating.  Some values may have been changed since it was last read"

I can manually update address information using MSSQL QA/MGMT Studio, but not with the SLX Client (6.2.6).  I have read where a similar issue occurred due to a date being close to DST, but I do not think that is the case here.  Has anyone experienced anything like this before?  Thanks.

That normally [always] occurs when the address lines don't "fit" the space allocated. For example, you try to push 65 chars into a varchar(64) field. You can test this yourself by editing addressline1 and putting in >100 chars. It will error with the same message. So, you should modify the edit form and set the MaxLength to the size allocated. This is a common issue with ADO.

I am having a tough time trying to isolate the issue at hand.  Thr process seems very basic, System - Add Edit Address is called, a query is executed to populate the form, the users makes changes, and then the form is posted back to update the original row of information.  The form itself has not been altered for years, so I am not sure that this is another example of SLX trying to squeeze too much data into a column.  Essentailly, it is as if the form loses the original ADDRESSID for the address that should be updated.

Are you getting this err on line 235 ?

I just fired up 626. In Address Line 2 I added: aldkajs ldkjasldkjaskjdlkasj dajs djaslkjd laskjdlaksjd lkasdlkj askdjlaskj dlaksj dlkjas ldlaskj dlkasjldkjaslkd laskj dlka jsldkjaslkjdlkjd laskjdgaskjd jahgdjasjhagkjag jahgd jhas djhgd jhas dhg jahs hagd jhagas jdhg a

*BOOM* - as expected. You can't replicate it because you aren't doing what the user is doing. But, the err is the same regardless - too much to fit within the col. Fixed in later versions.

BTW Meant to add - you will get this provided there is another (or more) contacts with same address. You'll need the prompt "Do you wish to update contacts with matching address" to appear. Hit OK - then the err will appear.

I can replicate what you just did, open the edit address form, enter garbage into address line 2, and then when I hit OK, I am prompted with an error directing me to the plugin and line of the occurence.  However, the original issue simply displays what I stated in the orginal post, i.e., the plugin is not referenced. 

In which case I'm struggling to understand what your issue is.

If you want to fix the error - fix the form (the one you already mention, the system Add/Edit Address) and change the MaxLength property for each column to the maximum size that the database column will handle.

If you want to fix the user error - I can lend you a baseball bat !

The error comes from the database having a limit for each column (address.address2 is varchar(64) for example). The garbage pasted in exceeds that when it comes to save/commit the data. Hence, the error. This is what your user is doing [exceeding the length nominated]. However, rather than silently suppressing the error (or truncating the data) then SLX reports this (as the err bubbled up from ADO).

I withheld some details with the hope that the original error message would be familiar or telling enough to diagnose the issue.  To add to this, SLX is integrated with Mas 500 (6.3), after we enter a customer in SLX, we go through a routine where the customer is migrated to Mas 500.  I am able to edit address information for test accounts that have not been migrated yet, but after an account is migrated to Mas 500, the user is prompted with the message in the original post.  So SLX seems to function as expected on its own, but when a connection is made to a customer in Mas 500, the address information is no longer editable. 

Sorry, have no idea about that.

The culprit was a trigger on the ADDRESS table.  If the account was not migrated to Mas 500 previously, the trigger fired, but with no matching information in Mas 500, the trigger woudl skip to the end.  After reviewing the logic of the trigger, we are back to being able to edit address information for accounts that have been migrated to Mas 500.  Did I mention that I do not care for triggers?

Phew, yes - triggers are the devil's work (handy, but always last to be thought about)