Borislav,

Thanks for the reply. I know what you are talking about with that. In this case the record has already been inserted (and the identify key field assigned) from a PHP web application when the consumer fills out an online form. The lead is collected on a website and I'm using VFP to process the lead.

I still hope to figure it out but I've already resigned myself to having to do a SQL passthrough to update the backend. For now I have turned off the 'SQL Update' and I'm just using the remote view as an non-updateable cursor. That way I don't have to change any of the interface or grid stuff and will just do a SQL passthrough to perform the update. It's like doing all the updates twice (once locally to the cursor and then once by hand to the backend) but at least it's a plan. Because of the way this app functions it will not be too bad to do it this way. Just irks me a bit that it's when the data doesn't change that it throws the error but when the data does change it does not error. Too weird.

Greg

>Greg,
>I never worked with MySQL, but when I work with SQL Server usually I got that error when I have the following situation:
>(Back end) Table has IDENTITY field (or any other automatically generated value) which is used for PK
>I add a new record
>Update table (w/o getting the key field back to my VFP cursor)
>Then I change some fields in the newly created record and try to send the changes back.
>
>
>>Greetings,
>>
>>Well as I feared in my previous post, my update problems have gone from bad to worse.
>>
>>The problem has to do with an updatable remote view hooked up to a MySQL back end. I've tried all the various update types - Key, modified fields, updatable fields, etc. and I still get the same update conflict behavior.
>>
>>Basically if the data in the field changes, there is no update conflict and everything works fine. Ironically if the same data is placed back in the field that was there previously, I get an update conflict error.
>>
>>Example:
>>
>>

>>** leads.dealerid = 0   The original value contains 0
>>SELECT leads
>>replace leads.dealerid WITH 1
>>SKIP
>>
>>** above code generates NO error
>>
>>
>>** leads.dealerid = 0    The original value contains 0
>>SELECT leads
>>replace leads.dealerid WITH 0
>>SKIP
>>
>>** Above code generates an update conflict error because the field contains the same value as before
>>
>>

>>
>>Before I was using a work around by checking the values before doing the replace, but as I feared the problem has become tougher to deal with. A bound combo box I added to the form throws the error when I move to the next record. Plus I've found that if you tab through textboxes everything is fine; but if you retype the same text into the textbox is generates the same error.
>>
>>I'd really like to get this problem figured out using the remote view as I have it bound to a complex Grid and lots of form controls and it would take quite a bit of effort to re-write this using SQL pass through. Part of it too is that it just bugs the heck out of me that it is doing this!! :)
>>
>>Anyone have any suggestions?
>>
>>Thanks in advance!!!
>>
>>Greg