>>I have an illusive problem that pops up about once a day. It's the 1585 error. The trouble is, the error comes up when adding a record and values in curval and oldval do not evalute, because no record exists (recno is -1). I have a VB programmer here that is writing to the same table that I'm getting 1585 on. I have finally been able to reporduce the error by having Fox sitting on the record when ADO updates the memo field. Then try to save an added record(Note: added while sitting on record updated by ADO) in Fox and I get 1585. On local testing I can say overwrte changes and that works(even though there is no real change to overwrite, rembember, its a new record). In live enviornment user cannot force update. I cannot get them to turn off this ADO VB $#&%$* so that I can verify it's the true problem. Seeing it happen in the test env doesn't seem to be enough. I have to hear it's a Fox problem. I think the third party data consumer needs to go.
>>
>>Any advise on why Fox might be seeing this as a 1585 ditry buffer is greaty appreciated.
>>
>>
>>Much Thanks
>>Jeff
>
>Jeff,
>Record is new and buffered and ADO updates it externally ???
No!

>Or it updates existing one you're on and you do an insert (in a row buffered table triggering update for existing) ???

Yes, this is exactly the case! But would adding trigger an update on existing row?

>If it's not in a DBC use a DBC and (VFP7 and later) turn DBCevents on to kick the other away - add code to dbc_OpenData, dbc_BeforeOpenTable or dbc_BeforeModifyTable that accepts only if a password is passed or checks attempter is a your VFP app :)
>Cetin

Yes it's in DBC but FOX 6.0. I'm trying to work with the VB guy, he's the IS Director for this company. I'm suggesting he put the info into SQL server, they have it here, and then I can just let FOX view it. I cannot shut him down. He would probably let me go. This app is so unstable that at this point I'm hoping ADO is the only problem.

Much Thanks
Jeff