>Svein,
>read the original code again!! This trigger is going to fire on **every**
>insert and blat whatever value comes through.
><g>

Reread as

if NotSuppliedPK
PK := GeneratorValue
else
if StupidlyAssignedPKValue > CurrentGeneratorValue then
Increment Generator to ValueEqualToOrGreaterThanStupidlyAssignedPKValue

Apart from the horrifying thought that someone has assigned the PK without
using the generator, I still don't see any danger (excepting overflow if
StupidlyAssignedPKValue is huge). I know that Temp_ID may not be current at
the time of incrementing the generator, but that should only mean that the
generator was increased by more than intended - never less. Am I still
asleep (I'm normally awake at 10AM in Norway) or is it my understanding of
'blat' that is missing? ;o}

Set

At 19:43 08.02.2001 +1100, you wrote:

>At 09:18 AM 08-02-01 +0100, you wrote:
>>Helen,
>>whereas I fully agree that mixing generators and other ways to assign
>>primary keys are bound to get you into trouble, I see Michaels code as only
>>an attempt to cover for stupidity in case someone should assign a PK
>>without using the generator. Note that he only increases the generator,
>>never decreases. This could lead to holes in the PK sequence, but not PK
>>violations due to the generator.
>>
>>Set
>
>Svein,
>read the original code again!! This trigger is going to fire on **every**
>insert and blat whatever value comes through.
><g>
>
>Helen
>
>
>
>>At 09:48 08.02.2001 +1100, you wrote:
>> >At 04:11 PM 07-02-01 -0500, you wrote:
>> >>Hello Paul
>> >>
>> >>GeneratorLinks is to allow IBO to go ahead and get the
>> >>ID of the record before the actual insert. This allows
>> >>it to pass it along to Detail tables that could be connected
>> >>and other things. You don't have to use it for positioning,
>> >>I think you are talking about keylinks.
>> >>
>> >>I use the following trigger on my tables:
>> >>
>> >> create trigger TRGBEFINS_Customer for Customer
>> >> active before insert position 0
>> >> as
>> >> DECLARE VARIABLE Temp_ID integer;
>> >> begin
>> >> if ((new.Cus_ID is NULL) or (new.cus_ID = 0)) then
>> >> begin
>> >> new.Cus_ID = gen_id (Gen_Customer_ID, 1);
>> >
>> >END THE TRIGGER HERE !!!
>> >
>> >The following code is !!!! dangerous !!!!. Generators operate right
>> >outside the transaction context. In a multi-user environment, you are
>> >certain to get PK violations. Don't do it!!!
>> >
>> >> end else begin
>> >> Temp_ID = gen_id(Gen_Customer_ID,0);
>> >> if (new.CUS_ID > Temp_ID) then
>> >> begin
>> >> Temp_ID = gen_id(Gen_Customer_ID, new.Cus_ID-Temp_ID);
>> >> end
>> >> end
>> >> end
>> >>
>> >>It will update your generator if necessary and also, make
>> >>sure that the generator doesn't get behind if you inserted
>> >>records that had IDs not derived from the generator.
>> >
>> >If you are using a generator to populate a primary key, you should NEVER
>> >try to insert rows where the PK comes from another source that **that**
>> >generator.
>> >
>> >To add a further note on GeneratorLinks, you should always use it when
>> >inserting into a bi-directional dataset, rather than waiting until after
>> >the insert has committed, to ensure that the KeyLinks will work
>> >properly. Reserve the use of the trigger for external clients or scripts.
>> >
>> >Helen
>> >
>> >
>> >
>> >
>> >All for Open and Open for All
>> >InterBase Developer Initiative · http://www.interbase2000.org
>> >_______________________________________________________
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>All for Open and Open for All
>InterBase Developer Initiative · http://www.interbase2000.org
>_______________________________________________________
>
>
>
>
>