> Jochem Maas wrote:
>
> >>>it sounds like 2 different insertions (via 2 different requests) where
> >>>the transactions are overlapping and the results of the one
> that started first
> >>>is not being seen by the one start second... I really
> recommend a generator
> >>>for the TICKET_NO.
> >>
> >>That would not help - I'd STILL get two records just with two different
> >>TICKET_NO's
> >
> > right but you wouldn't have the race condition anymore with
> rtegard to TICKET_NO
> >
> >>I dropped the generator because of problems getting it reset to '0' at
> >>the start of each day - it just was not happening in some offices so
> >>they were ringing up and saying 'We haven't started at 1,
> somethings not
> >>working!' - Things would be fine without customers :)
> >
> > I can hardly imagine that could not be solved with a stored
> procedure or two
> > that the insert trigger would call... I actually have some
> 'sweepstake' related SQL
> > that automatically creates/removes generators based on records
> (that each represent
> > a 'sweepstake') being inserted/deleted with the relevant
> dynamically created
> > generator being used for tickets(entries) for each sweepstake.
>
> Actually the sweepstake is simply the browser - ever tried double click!
> Double click gives two clean tickets every time :(
> So the problem is nothing to do with Firebird - just a matter of
> stopping PHP running the script twice!

that's simple - just a javascript gate to stop 2 posts
Alan

>
> > one has to question why the ticket numbers must start at 1 each
> day - although
> > without konwing all the context and background it's impossible
> to judge the 'correctness'
> > of such an implementation (not to mention customers often
> require stuff that make your
> > toes curl ;-)
>
> Customers are called to a counter or room by ticket number - need I say
> more ;)
>
> --
> Lester Caine - G8HFL