Is it possible that you somehow created double buffering? E.g. you buffered view and a table?

>Thanks for the quick reply Himlat. Unfortunately I am still having the problem. I used your code and the TABLEUPDATE() is not failing. It is just not updating as well. I added a messagebox displaying the contents of the field (tablename.fieldname) and it shows the correct (changed) data. But when close that form and reopen it, it beocmes obvious that the data was never saved.
>
>The application is multi-user, but I can recreate the problem on a development machine with only myself. It is on a local drive with full permissions and there is plenty of disk space. There are also no tiggers being used in the application. I guess I just assumed that the TABLEUPDATE() was failing. I guess the problem lies somewhere else?
>
>>>Hopefully a quick question. I am supporting an old VFP app and I am not that good at using cursors and such. I have a product screen that manages 4 types of products. Each type has a different database view. The view in question (desspview) inclues all the fields on the original table (design). There are two filters in the view. One is hard coded to select that specific type of product. The other is one with a ? - i.e. ?curdescode. The user is able to update a field in the view called embcolor1 by populating a text box and clicking on a button. This is the code that is executed when they click the button:
>>>
>>>REPLACE desspview.embcolor1 WITH ALLTRIM(THIS.PARENT.text3.VALUE)
>>>
>>>When they exit the screen, they click on the save button and the following code is executed:
>>>
>>>TABLEUPDATE(2,.T.,'dspecview')
>>>TABLEUPDATE(2,.T.,'desspview')
>>>TABLEUPDATE(2,.T.,'embspecview')
>>>TABLEUPDATE(2,.T.,'desembview')
>>>SELE desview
>>>REPLACE desview.desrevision WITH DATE()
>>>TABLEUPDATE(2,.T.)
>>>THISFORM.RELEASE
>>>
>>>In the end, the table design is not updated. I am being told this used to work but no longer does. I don't believe any changes to this area of the system has been made in years. Any ideas?
>>
>>TableUpdate() can fail for several reasons. The programmer should check whether it was successful, and why it wasn't.
>>
>>Some reasons a TableUpdate() might fail:
>>

The table is R/O.
>>

A field or record rule is violated.
>>

RI is violated.
>>

Some other trigger is validated (RI is implemented through triggers, too).
>>

Update conflict (another user tries to save data at about the same time).
>>

Disk full.
>>

Insufficient access rights. This happens especially on shared drives.
>>
>>Sample code:
>>
>>

>>local laError
>>if not TableUpdate(...) && TableUpdate() returns .T. if successful
>>  aerror(laError) && Copy error information to an array
>>  MessageBox("Error saving table xyz, error #" + transform(laError(1));
>>    + " error message: " + laerror(2)
>>endif
>>

>>
>>Of course, you should do this check for every table you save.
>>
>>You might also check whether the view definition changed.
>>
>>HTH,
>>
>>Hilmar.

If it's not broken, fix it until it is.


My Blog