At 11:41 AM 02-02-02 +0000, you wrote:

>Bingo, that's correct, Geoff -- no defined PK causes the problem.
>
>I've also discovered that the following trigger (before insert) can
>cause the problem...
>
> new.F_PK = gen_id(gen_shared, 1);
>
>This trigger automatically assigns the next gen_id to the PK
>regardless of value entered (and a value must be entered when working
>from grids because of the NOT NULL field status). When inserting a
>record via grid, if I type in a PK value (a dummy value) higher that
>the last record PK value then the inserted record drops off grid. If
>I use a PK value of 1, the record remains visible after post.
>
>The switching of the PK value at trigger level is tripping up IBO's
>record handling on some level, perhaps.
>
>The trigger issue is a bit of a weird case in that I may be using the
>gen in a way that's way off norm. I'm too new at this to know.

Andrew,
the missing magic wand (in your applications) is GeneratorLinks. Instead of letting the trigger get the generator value, let IBO get it into the new row before it ever gets posted.

Find the GeneratorLinks property and fill it like this:

F_PK=GEN_SHARED

AND you must change your trigger to this:
..
if (new.F_PK is null) then
new.F_PK = gen_id(gen_shared, 1);

For messing about in IB_SQL, you could change your trigger to this:

..
if (new.F_PK is null or new.F_PK < 0) then
new.F_PK = gen_id(gen_shared, 1);

and then just put "-1" into the F_PK column of the grid. That will cause your generator to fire properly.

However, it's better practice for a newbie not to use the dataset grid for entering "practice data". Use the DSQL tab in the main form for DML like updates, inserts and deletes and omit the PK value altogether from the SQL statement, use the Cursor tab for selects.


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at www.ibobjects.com