Thanks for the clue!

It seems some dba decided to add in a default mechanism to the table I am accessing that for some reason changes a key value. The keys came across from sql server so the default just came into the view. I changed the view so that the key is based on the fields that are not modifiable and everything now works great.

Thanks again.



>>I've come across a little glitch in some code that has stumped me. Maybe someone out there can give me some idea on how to resolve.
>>
>>I have a remote view that is tied to a sql server backend table. It is a remote view to one table only. No muli tables are being used.
>>
>>In code, I am deleting data in a memo field for a record and then setting up a transaction save to sql server. Upon issuing a tableupdate(2,.t.,alias(),aSaveError), I get a return of .t. that the update ocurred and that no errors were logged to the error array.
>>
>>When you browse the sql server data, the changes were not made. When you browse the view following the tableupdate, the record that was modified is no longer there. But yet it exists on the sqlserver data with the old data.
>>
>>Any ideas on what could be going wrong? BTW, this is in VFP 5.0a. The client is not able to move to 6.0 at this time.
>>
>>Pat.
>
>You'll see similar behavior when you issue a TABLEUPDATE() and the key fields in the view did not match any key fields in the base table. The view record will be deleted. Is this possible for whatever reason?