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
©2006 Carl Karsten |
