Mark,

I was experimenting with the triggers and found something interesting. I was under the impression that my trigger was creating a second update and causing an update conflict. After removing the trigger I was still receiving an error when issuing the tableupdate with a force value of .f.

Here is what I think is happening. Say the value of the field in the Oracle table is trimmed. When foxpro creates a cursor from that record that field in the cursor has the padded spaces. Consequently when you issue a tableupdate with a force value of .f. foxpro compares the oldval of the cursor to the oracle field value and the two are different thus generating an Update Conflict.

Do you have these same problems in you apps?

Matt

>Yes you are right. I just don't understand why VFP would see this as an update conflict because you are only changing the value of the data being sent back to the table and not the current value in the table.
>
>>Mark,
>>
>>Wouldn't the Trigger above reset whatever the new changes are back to what was in the table?
>>
>>Any way I did create triggers on the Oracle side. They were very similar to the one above with the one exception.
>>
>>

:new.VarCharField1 := rtrim(ltrim(:new.VarCharField1))

>>
>>The Problem with doing that was when issuing a tableupdate with a force value of .f. an error occured. The trigger changes the values of the table causing VFP to see this as a change by another user (since the trigger is executed by the server). Thus I get an error unless I set force to .t. and there are instances where business logic will not allow a force value of .t.
>>
>>I will keep digging. If you come across anything please let me know.
>>
>>Matt