>Hi Jeff,
>
>The code you posted shows optimistic locking, not pessimistic. Can you clarify that?
>
>>I'm working on an application that is having some serious, though intermitant, conflicts in the multiuser enviornment. I found out there's a VB programmer that is writing data to the memo field. He said he's using pesamistic locking, but I wonder if ADO might be locking the table header in the memo file. I'm starting to write some test code right now to see if I get contention. Apparently the VB code is not called very often, and I don't have conflicts very often.
>>
>>below is connection code and record set code I received from the VB guy.
>>Any thoughts apprecitated.
>

>connstr = "Provider=MSDASQL.1;Persist Security Info=False;" + _
>>             "Driver={Microsoft FoxPro VFP Driver (*.dbf)};" + _
>>             "UID=;SourceDB=" + Source + "\;" + _
>>             "SourceType=DBF;Exclusive=No;BackgroundFetch=No;" + _
>>             "Collate=Machine;Null=Yes;Deleted=Yes;"
>

>>TJrst.Open sqlstr, TJcnn, adOpenKeyset, adLockOptimistic
>>
>>
>>TJrst.Update
Yes, it is optimistic. I wrote wrong in original thread. BTW, I finished the test code last week and the result is as follows.

I can get a 1585 error if I'm sitting on a record in FOX and update it with ADO. Now if a new record is added in FOX from sitting on the same record that was updated in ADO I get the 1585(updated by another user error). Very Strange. The live app bombs if you attempt to resole error by saying yes to overwriting other changes(but not really, rember I'm adding and recno is -1) app bombs. In test enviornment if you say yes it saves the new record. This is killing me, I working with the VB guy, who by the way is also the IS Director of the company.

I also have another thread (ADO updating memo field) The field that he is updating via ADO is a memo, so I have the memo table involved.

Much Thanks Sergey
Jeff