>Hi Jim,
>>Seems I started a new discussion. Your point is good. This is not a reply but rather my addition.
>>Sometimes I have other situations where I really want to lock all recs in a session. ie: I have an employee tracking and want to revise their records as a supervisor (or boss). I do not want anyone to tamper while I'm doing it on per topmost parent basis (I want topmost parent+allchilds locked). Pessimistic buffering would be the one I would choose. But instead I could prefer a transaction and maybe just use it as a safety belt. Needs arise sometime. As always there are many ways to skin a cat in FP. So IMHO while transactions and buffering are in close relation none is dependant to other.
>
>
>Cetin,
>
>You came into this late in the game. Your issue was discussed days ago. Buffering and transactions have nothing in common outside fo the fact that they are involved wiuth updating data. They do totally independent things and are both useful in their respective areas.
>
>In your example I would use optimistic buffering (as that is what I always use, Optimistic tabel buffering). I would handle the administrative issue by either using a semaphore locking scheme or by programmatically obtaining all necessary locks before allowing the administrative action to begin. Transactions are reserved for combining multiple table updates (including deletes and inserts as well) into a single all or none operation. I don not use them to control locking although is could be done.
>
>The difference would be that using my approach above I would secure all locks before I would allow the user to do antyhing. Then when the user was finished I woudl still use a transaction to wrap teh updates. Using a transaction each lock is obtained as teh table is updated. This means that the user can do some of the work and then get told the task cannot be completed.
>
>Why also use a transaction? Becasue there are things that can happen that could allow the lock to obtained but then disallow the tableupdate from executing (like network cable broke, administrator shut down the server, etc.)
Yeah came late :) and in fact not telling much different (..many ways to skin a cat...).
I really appreciate transactions + buffering being introduced in FP.
I'm afraid this would prove "elephant hunt" about foxers :) Here is that for some fun (dated Dec 17th,1993):
+----------------------------------------------------------------------------+
How Programmers Hunt Elephants
CLIPPER programmers don't actually hunt elephants, they just buy libraries of
elephant parts and then spend years trying to integrate them.
DBASE programmers only hunt elephants at night when no one will notice that
they are still using crossbows.
FOXPRO programmers switch to newer and better rifles every few days which
causes then to spend learning new shooting techniques than actually hunting.
C programmers refuse to buy rifles off the shelf, preferring to take steel
rods and a mobile machine shop to Africa intending to build the perfect
rifle for the job from scratch.
PARADOX programmers go to Africa with copies of Hollywood movie scripts about
elephant hunting, the renactment of which they believe will help them catch an
elephant.
ACCESS programmers zero right in on an elephant right away, even with no prior
experience in elephant hunting, and then, impeccably dressed and fully looking
the part, get the elephant in their beuatifully-mounted scopes, and then
realize that other than missing a trigger, they are 99.9% 'there'.
RBASE programmers are rarer than elephants. In fact, when an elephant sees an
RBASE programmer he considers it a luck day.
VISUAL ACCESS programmers point at their bullets, point at their rifles, then
point at the elephant. This amuses the elephants, who run away. They are
unable to persue the elephant because their jeeps are undriveable having
steering wheels, yokes, joy sticks and rudders, due to their love of multiple
controls.
ADA, APL, and FORTRAN programmers are just as fictional as Santa Claus and the
Tooth Fairy.
COBOL programmers have too much empathy to hunt another near-extinct species.
+----------------------------------------------------------------------------+
Cetin
