The main difference is that a Generator is more like an Oracle Sequence,&nbsp;<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">&lt;<a href="mailto:neven@mwk.co.nz">neven@mwk.co.nz</a>&gt;</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), &nbsp;this has been &#39;fixed&#39; 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 &#39;serial&#39;, which auto<br>
generates a &#39;sequence&#39;<br>
<br>
Of course I could be spouting BS.<br>
<br>
Neven<br>
//<br>
<div><div></div><div class="Wj3C7c">&gt; Whats others opinion on the merits of trggers etc as discussed here vs the<br>
&gt; Firebird/Interbase method of using generators?<br>
&gt;<br>
&gt; I have often wondered if this is an area where Firebird/Interbase has a less<br>
&gt; convenient but more transparent mechanism - where you have to fire a<br>
&gt; generator to get a new key value before you start putting data in a new<br>
&gt; record.<br>
&gt;<br>
&gt; And the generator never rolls back even if the transaction does - avoiding<br>
&gt; the lock problem. &nbsp;Mostly in<br>
&gt; my experience this is fine, except some times when the ID numbers (eg batch<br>
&gt; numbers) are supposed to be strictly sequential and then you have to get the<br>
&gt; next value from a SQL query, and make sure no-one else is running another of<br>
&gt; the same batch at the same time. &nbsp;(In those situations the main thing that<br>
&gt; protects the database is that only one staff member ever runs this batch<br>
&gt; operation - I bet thats how a lot of databases run in practice)<br>
&gt;<br>
&gt;<br>
&gt; John<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; NZ Borland Developers Group - Delphi mailing list<br>
&gt; Post: <a href="mailto:delphi@delphi.org.nz">delphi@delphi.org.nz</a><br>
&gt; Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
&gt; Unsubscribe: send an email to <a href="mailto:delphi-request@delphi.org.nz">delphi-request@delphi.org.nz</a> with Subject: unsubscribe<br>
&gt;<br>
&gt;<br>
&gt;<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>