My guess is your WhereType property is set to 3 instead of 1. See VFP Help on WhereType on what these values are. The problem with VFP is the cahracter fields and Oracle's VARCHAR data types. Your VARCHAR2 fields do not have any RPADded values. When VFP sends updates back to Oracle, it sends the Character data back RPAdded with spaces. This caused the conflict if the WhereType is 3 [or not 1].

If you use the CursorAdapter, you can use the ConversionFunc to RTRIM the values going back to Oracle for your character data. My CursorAdapter VCX Builder will also help you -- click the FoxTools link at http://www.mctweedle.com

>Hi,
>
>Has anyone got VFP 8.0 with an ODBC connection working to allow updating of an Oracle backend. The same ODBC connection with MS Access works 100% using
>MS Oracle ODBC driver and Oracle ODBC driver. Works 100% with VB and 100% with Visdata.
>I went out an purchased a 3rd party ODBC driver for Oracle and now got the same issue.
>Works 100% with everything except Visual FoxPro. In this case I wrote an interface in Visual Basic and this works 100% updating the Oracle backend.
>For some stange reason in VFP the remote view will not update to the backend.
>In VFP I make my record edit changes and when I move my record pointer get the Update conflict error message. So as per the VFP help issue a forced update =tableupdate(.t.,.t.) Tried =tableupdate(0,.t.) =tableupdate(1,.t.) and =tableupdate(2,.t.)
>
>All marks the record like it was deleted in a browse window, but moving off the record no more errors.
>Close up the remote view and open it again, and no changes to the backend were committed.
>I have my remote view set up for updating all fields. The Send SQL updates is checked, the SQL WHERE clause includes "Key and modified fields"
>The Update using is set to "SQL UPDATE"
>
>I have tried setting buffering to 5, and same issue.
>
>If I cannot get this resolved my only course of action is to write the entire interface in Visual Basic and not user Visual FoxPro.
>I sure hope someone out there has a suggestion for me, as the 3rd party ODBC driver costs $600.00 and it does not work...ugggg!
>
>By the way I am running v.8.1.5 as my Oracle backend.
>
>Pete,