Subject | Re: [IBO] Is GeneratorLinks done on client? |
---|---|
Author | Helen Borrie |
Post date | 2001-03-14T00:49:24Z |
At 03:19 AM 14-03-01 +1000, you wrote:
CREATE TRIGGER GET_GEN_ATABLE FOR ATABLE
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
IF ((NEW.IDFIELD IS NULL) OR (NEW.IDFIELD = 0)) THEN
NEW.ID = GEN_ID(GEN_ATABLE_ID, 1);
END
You never get key violations with generators. They are right outside transaction control - once the number is generated, it can't be generated again. This also means that, if the transaction rolls back, that number will never be used. Just make sure that you don't create any dependencies on this serial number.
Generators on their own (without some programmed support in the database) are not recommended for a strict serial number system if gaps are not allowed. There is a TI sheet, with a sample project and database, on a technique for maintaining such a system - see http://www.ibobjects.com/TechInfo.html.
Cheers,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
>Does GeneratorLinks work with a server before insert trigger?No, it works *instead* of the Before Insert trigger. Because it fetches the next value of the generator, you must make sure that your trigger tests for a value before applying another one, i.e.
CREATE TRIGGER GET_GEN_ATABLE FOR ATABLE
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
IF ((NEW.IDFIELD IS NULL) OR (NEW.IDFIELD = 0)) THEN
NEW.ID = GEN_ID(GEN_ATABLE_ID, 1);
END
>I have a generator and a before trigger to assign it to the PK of a table.If you don't want IBO to fetch the generator value, remove the GeneratorLinks entry for the column.
>I found that IBO incremented the generator before inserting and since I did
>not include the field involved in the INSERT statement, the generator on the
>server incremented the generator again (since the field is null).
>My question is: Is it a good idea to increment the generator from theFor a primary key it is better to use GeneratorLinks and include the column in the insert SQL. If you are using the generator column for something else, like a serial number, it's probably better to let the trigger do the work. However, if your app needs to know the generated number before the new row commits, you should use GeneratorLinks.
>client? Will there be a keyviol problem where two clients are simultaneously
>incrementing the generator?
You never get key violations with generators. They are right outside transaction control - once the number is generated, it can't be generated again. This also means that, if the transaction rolls back, that number will never be used. Just make sure that you don't create any dependencies on this serial number.
>I suppose not since the generator on the server should be serialized.The IB generator mechanism absolutely guarantees serialization, **as long as** you don't give your SYSDBA or any of the applications the ability to reset the generator value.
>However, is it possible for IBO to:Yes: by omitting the column from your insert SQL or by intervening before posting and setting the column to NULL (FieldByName('MySerialColumn').Clear).
>
>Perform insert (omitting the PK which is generated using server trigger),
>then after that, loads up the value of this field from the server.
Generators on their own (without some programmed support in the database) are not recommended for a strict serial number system if gaps are not allowed. There is a TI sheet, with a sample project and database, on a technique for maintaining such a system - see http://www.ibobjects.com/TechInfo.html.
Cheers,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________