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
