hi helen:

i can�t understand why wait transantion can�t be used, if i want a
trasanction wait until the first transaction commit the change, then, when
first transaction finish, last trasaction can continue the actions. Where is
the conflict?, i don�t want the last trasaction comeback and show a message
to the user saying "the record is using, retry later".

Can you help me to undestand?. Maybe my problems is in the way to implement
the counters.

I think too that generator is not a good option because the counters would
be consecutive
1,2,3,4,5.

Thank in advance
Danny

"Helen Borrie" <helebor@...> escribi� en el mensaje
news:5.1.0.14.2.20020625223325.0971acf0@......

> At 12:09 PM 25-06-02 +0200, you wrote:
> >Hi All,
> >
> >I'm having a conflict with a wait transaction (free ib components). In

the

> >client front i have a exec query asociated with a wait trasaction. This
> >query execute a SP from the database.
> >
> >create procedure getcounter(type char(3)) returns (counterValue smallint)
> >as
> >declare variable tmpCounter smallint;
> >begin
> >
> >select counter from counters
> >where (type = :type)
> >into :tmpCounter
> >
> >if (tmpCounter is not null) then
> > begin
> > tmpCounter = tmpCounter + 1;
> > update counters
> > set counter = tmpCounter
> > where (type = :type);
> > end
> >end
> >
> >When two or more client's front call SP only one of them get the

correct

> >values of counter, the other client frontl look like nothing was happen

(is

> >comming back to the last state before start de trasaction). I 4m sure the
> >trasaction is comming back without wait. Can any body say me where could

be

> >the problem? Maybe inside Free-IB Transaction component, or maybe a
> >conceptual problem of mine.
>
> Sadly, it's a conceptual problem. This approach to serial number
> generation works great on a desktop database with a single user. You will
> need to abandon it for mult-user purposes as it's unsafe; and the lock
> conflicts protect you from doing it.
>
> Don't set this transaction to WAIT. Make it NO WAIT and force your
> application to roll back all transacs that encounter a lock conflict.
>
> But don't persevere with this approach. Find another way to generate your
> counters. The obvious one is to use a generator, which will perform the
> incrementing for you and always guarantee that the number will get
> incremented in strict sequence.
>
> heLen
>
>
> All for Open and Open for All
> Firebird Open SQL Database 7 http://firebirdsql.org 7
> http://users.tpg.com.au/helebor/
> _______________________________________________________
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>