johnf wrote: > On Saturday 30 December 2006 07:55, Carl Karsten wrote: >> 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 > > Just to be sure everyone understands. My question "What happens" wasn't a > request to change anything. I just wanted to know what Dabo was doing > currently.
Me too :) I have a hunch, but haven't figured out where to look to verify it. > > I recall a thread where the issue of how to use the special features of > database engines were discussed. Of course it was determined that Dabo would > not support each database engine completely only the standard "create, > insert,update, etc" commands. > What I am talking about is using a standard SQL UPDATE command, and then looking at how many records were updated (which may not be standard) to detect a collision. If the 'how many' is not standard, then I would think it would be part of the various classes that are specific to each db. > This does not prevent the developer from adding code to support any feature. > In fact (if memory serves) at one time I had code in dbPostgres to auto > commit and few other features. > > It's not that special or different features can't be supported. In fact Dabo > makes special considerations for the way each database limits the number of > records. i.e. MsSQL uses the word "TOP" just after the "Select" and > Postgres uses "Limit" at the end. Take a look at getLimitWord and formSQL of > dbMsSQL.py > > _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
