Ed Leafe wrote: > On Dec 29, 2006, at 8:15 PM, Carl Karsten wrote: > >> VFP's conflict detection dosen't happen until after the SQL UPDATE >> command is >> processed by the server. so I don't see how that is "ahead of time." > > All it does is pad the WHERE clause with additional filters: > > ...WHERE pk = (pkVal) > AND updateField1 = oldval(updateField1) > AND updateField2 = oldval(updateField2) > AND updateField3 = oldval(updateField3) > AND updateField4 = oldval(updateField4) > ... > > If any of the fields have changed, nothing gets updated, since the > WHERE won't match. This is very different than issuing an update and > having the server actively reject it due to a modified state and/or > transactional lock. > >> What backend would prevent an UPDATE command from updating that >> would update on some other server? we are talking standard SQL >> UPDATE command, right ? > > There are transactional features and locking features that vary from > backend to backend. It isn't the UPDATE statement that's the issue.
"If a user is about to update the database and someone has changed the backend data. What happens?" I think the answer should be: "It depends on which WhereType you are using: either the first update gets overridden, or your update doesn't update." I am guessing dabo does "WHERE pkFIled = pkValue" and so currently the answer is "the first update gets overridden." - right? Carl _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
