Woody wrote:

> I think you've been lucky up until now not running into any problems with
> the way you're doing it now. I have dealt with people who leave for lunch or
> even for the day without closing a form and saving information right away so
> I try to make it as non-interfering as possible so it doesn't cause others
> to have problems. It doesn't always work but it gets close.

Should have mentioned ... this is a PHP web based application ...

Transaction is always closed when a page is generated, but something is going
screwy on this site as I've had another couple of different problems today. The
'id' that I am using MAX+1 for is only created IN the trigger when a ticket is
moved between 'locations', so when called from a queue, or referred to a queue.
Leaving it open at a location is not a problem, but no one else can do anything
with that ticket until it's put back to the queue, yet in this case there was a
second set of 'details' with the same transaction_id (2,3,4) as the first person
who called, served and cleared that ticket ... which would have been three
separate transactions over in this case 70 seconds ... and the second set of
id's are over a further 90 second time frame. These should all have had to be
giving errors, yet the rogue data existed and was not rolled back? AND since the
sequence was incremented a second time, the new data must have been visible to
the new transaction - which what I can't understand.

There is some major working being done to the NETWORK on the site, which while
it should not affect things obviously is :( Just no explanation at the moment as
to why or how ... so I'll just have to keep an eye on things a little longer.
Would be a site that opens Saturdays :(

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php