John Really interbase generators are more akin to the mssql identity column type, the problem with mssql identity columns WAS with the @@Identity variable which was per connection (and hence triggers that inserted other identity columns not return the identity you would expect), this has been 'fixed' with the SCOPE_IDENTITY() function
Stangely identity columns and generators behave the same way, ie they are both not rolled back by a trans PostgeSQL, uses a combo of both a column type of 'serial', which auto generates a 'sequence' Of course I could be spouting BS. Neven // > Whats others opinion on the merits of trggers etc as discussed here vs the > Firebird/Interbase method of using generators? > > I have often wondered if this is an area where Firebird/Interbase has a less > convenient but more transparent mechanism - where you have to fire a > generator to get a new key value before you start putting data in a new > record. > > And the generator never rolls back even if the transaction does - avoiding > the lock problem. Mostly in > my experience this is fine, except some times when the ID numbers (eg batch > numbers) are supposed to be strictly sequential and then you have to get the > next value from a SQL query, and make sure no-one else is running another of > the same batch at the same time. (In those situations the main thing that > protects the database is that only one staff member ever runs this batch > operation - I bet thats how a lot of databases run in practice) > > > John > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: delphi@delphi.org.nz > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe > > > _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
