radevo:

That's the way Id's work: they don't need to be sequential, just
incremental. What's the problem of loosing some? You are not using
generators to keep a sequential number range, are you? If so, pls take a
look at this document:

http://www.ibobjects.com/docs/ti_AuditableSeries.ZIP

You may ask yourself why this is done by IBO on 'new record' instead of
'before post', and I think this is done to allow the user to know that value
at anytime, allowing for example this id to be use in a master/detail
relation ship (but Jason or Helen could explain better the reasons to you).

But the client should know that value before it sends it to the server, so
he can pick up just that row, instead of all query.

Your code in trigger:

> If (new.primary_id is null) then new.primary_id = Gen_ID(...).

is a very efficient, that keeps that rule also in the server, so you can use
another application (such as ibconsole, for example) to insert data into the
database with the same rule.

There is a 'feature request' post from Jason to Firebird that will resolve
this problem: a syntax in Firebird that will allow something like 'INSERT
.... INTO .... RETURNING :....' (I'm not sure if this is the syntax that
Jason ask for). This will allow to insert values returning another one, that
will simplify this problem.

I hope this helps.

Artur

----- Original Message -----
From: "radevojvodic" <rvojvodic@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, April 17, 2002 9:28 AM
Subject: [IBO] GENERATORS


> Hi All,
>
> I'm thinking about GeneratorLink usage and i find it unefficient. For
> example if you set this property for a primary key and you put your
> query in insert state generator is called imedietly. So you
> incremented generator value. Then You cancel insert and your
> generator value is still incremented.
>
> For some tables in database i wrote trigger with
> If (new.primary_id is null) then new.primary_id = Gen_ID(...).
> Now if you set you Insert statement in IBO_query to
>
> INSERT INTO *TABLE*( primary_id, ... ) Values (null,...);
>
> then your generator will be incremented only when you actually post
> your record to database and you are still able to enter your own
> value for that field without incrementing generator. Of course if you
> cancel transaction after you posted record generator will stay
> incremented but how often do you cancel transaction after you posted
> record.
>
> The only problem with this kind of solution is with refreshing query
> because new value is not shown until you refresh query.
>
>