hi Andrea!,
We had the same problem a while ago, in our case we were updating date fields
to a SQL Server back end from Visual Foxpro. We were changing the "DateTime"
from SQL to a regular FoxPro "Date", so the user won't see the time part of the date, what happend was that when we send the date back to SQL it was sent with
a different time stamp, in example:
01/12/2001 10:30:45 , was the original date in SQL
01/12/2001 , How we show the date to the user
01/12/2001 00:00:00 , How we sent back the date to SQL
Boom conflict 1585

So, what we did?, we do not include the TimeStamp in our remote views, that fixed the problem, also when we use stored procedures in SQL to update date fields we make sure that the field is updated with that date at midnight, that is, if I want to update a date field with 01/12/2001 I use 01/12/2007 00:00:00

Hope this help you.



>Hi,
>
>we are having problems with 1585 update conflict errors.
>
>The thing is that this error simply should not exist in our case.
>
>We have table buffering (5) enabled and are adding records
>to several tables. We are not doing any update. We simply
>do an append blank and replace fields.
>
>Sometimes (very seldom) we get this 1585 error (always in the add mode).
>This happens in single user environments with one form open as well as in network environments.
>
>I'm a bit worried if it makes sense to use the force option
>in a table update. This would be a good choice if there were a
>bug with the firing of this error. On the other hand I'm afraid to use "force"
>that this error may have its good reason and I will overwrite
>some data.
>
>Thanks in advance for any suggestions.
>
>(I canot switch to Insert SQL in the short run).
>
>Andreas