Ed Leafe wrote: > On Dec 30, 2006, at 10:55 AM, Carl Karsten wrote: > >> "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." > > The answer is not that simple. It depends on the backend you are > using, the locking schemes being used, etc. It also depends on your > code; you can make it behave however you want.
by "make it behave" you mean "write code" not set a dabo prop, right? > >> I am guessing dabo does "WHERE pkFIled = pkValue" and so currently >> the answer is >> "the first update gets overridden." - right? > > Probably. Unless your database somehow tracks changes by connection, > and refuses updates to stale data based on that. Or unless someone > else has locked that record and the database blocks the update. > > I discovered that using anything but WhereType=1 in VFP to be god- > awful slow. It shouldn't be. There are 2 places that I can see a bottleneck: client side when it is looping through all the fields looking for updates, server side: um... parsing the list of AND's? The actual query shouldn't be any slower than a simple PKField=val, because that is going to be part of it, and the engine should do that first, which will find the 1 record, then it will evaluate the rest of the fields=value's. > In fact, I wrote my own conflict checker and added it to > Codebook (dunno if it ever made it into VFE). Since I had some > logging code in their to check the coverage, speed, etc. of the code, > I left it in when I first deployed it on a client site. There were > nearly 300 people simultaneously using the app, and I logged every > time that one user tried to update a 'dirty' record. In the six > months I had that running, there was not a single case where this > happened. Why? Because we designed the app to be smart. Each person > was working on one particular record, which was marked by a > semaphore. Once marked, no one else could edit it. Explains why no one ever tried to update a dirty record: the app wouldn't allow it. > This was highly > desirable, since each record represented a different contract, and > there shouldn't be two reps working on the same deal at the same time. > > This is why I think that handling this sort of issue belongs in your > code, not Dabo's. > I fail to see how that supports your point. Everything could be done in the app, and nothing in the framework. Not sure that makes a valid for why something should not be in the framework. To me, collision detection is a framework thing. It is something 'the average database app developer' is going to want. Which is the point of a framework, right? The use case for this whole thing is resource allocation: you have a inventory of widgets, 2 people trying to sell them, and you don't want the same widget sold twice. Much like I want the database engine to make sure I don't create orphan child records, I want some low level generic code that makes sure database updates don't get overridden. I doubt I am the only one. btw - I am just advocating the detection be handled by the framework. What is done about it I am less concerned about. Carl _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
