The main difference is that a Generator is more like an Oracle Sequence, <div>It is table independant, which allows you to use the same sequence accross more than one table,</div><div>and you can also have more than one per table. I find the identity is only useful if it is to be a primary key, not useful as a data element.<br>
<br><div class="gmail_quote">On Mon, Dec 1, 2008 at 5:12 PM, Neven MacEwan <span dir="ltr"><<a href="mailto:neven@mwk.co.nz">neven@mwk.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
John<br>
<br>
Really interbase generators are more akin to the mssql identity column<br>
type, the problem with mssql identity columns WAS<br>
with the @@Identity variable which was per connection (and hence<br>
triggers that inserted other identity columns not return the identity<br>
you would expect), this has been 'fixed' with the SCOPE_IDENTITY() function<br>
<br>
Stangely identity columns and generators behave the same way, ie they<br>
are both not rolled back by a trans<br>
<br>
PostgeSQL, uses a combo of both a column type of 'serial', which auto<br>
generates a 'sequence'<br>
<br>
Of course I could be spouting BS.<br>
<br>
Neven<br>
//<br>
<div><div></div><div class="Wj3C7c">> Whats others opinion on the merits of trggers etc as discussed here vs the<br>
> Firebird/Interbase method of using generators?<br>
><br>
> I have often wondered if this is an area where Firebird/Interbase has a less<br>
> convenient but more transparent mechanism - where you have to fire a<br>
> generator to get a new key value before you start putting data in a new<br>
> record.<br>
><br>
> And the generator never rolls back even if the transaction does - avoiding<br>
> the lock problem. Mostly in<br>
> my experience this is fine, except some times when the ID numbers (eg batch<br>
> numbers) are supposed to be strictly sequential and then you have to get the<br>
> next value from a SQL query, and make sure no-one else is running another of<br>
> the same batch at the same time. (In those situations the main thing that<br>
> protects the database is that only one staff member ever runs this batch<br>
> operation - I bet thats how a lot of databases run in practice)<br>
><br>
><br>
> John<br>
><br>
> _______________________________________________<br>
> NZ Borland Developers Group - Delphi mailing list<br>
> Post: <a href="mailto:delphi@delphi.org.nz">delphi@delphi.org.nz</a><br>
> Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
> Unsubscribe: send an email to <a href="mailto:delphi-request@delphi.org.nz">delphi-request@delphi.org.nz</a> with Subject: unsubscribe<br>
><br>
><br>
><br>
<br>
_______________________________________________<br>
NZ Borland Developers Group - Delphi mailing list<br>
Post: <a href="mailto:delphi@delphi.org.nz">delphi@delphi.org.nz</a><br>
Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
Unsubscribe: send an email to <a href="mailto:delphi-request@delphi.org.nz">delphi-request@delphi.org.nz</a> with Subject: unsubscribe<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Kyley Harris<br>Harris Software<br>+64-21-671-821<br>
</div>