--- In firebird-support@yahoogroups.com, "Gaurav Sood"
<sood.gaurav@...> wrote:

>
> I found there is a separate trigger for PeopleID as follows;
>
>
> CREATE TRIGGER CREATEPEOPLEID FOR PEOPLE
> ACTIVE BEFORE INSERT POSITION 0
> AS BEGIN
> NEW.ID = GEN_ID(PEOPLEIDGEN, 1);
> END ^

This will always assign a new generated value to ID. This is a valid
way of doing what was done in Delphi, however be aware that in FB 1.5
you have no way of seeing the value of NEW.ID if you do it this way.

A better approach is

CREATE TRIGGER CREATEPEOPLEID FOR PEOPLE
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
IF (NEW.ID IS NULL) THEN
BEGIN
NEW.ID = GEN_ID(PEOPLEIDGEN, 1);
END
END
^

This will only generate an ID if you do not explicitly define one.
Think of a generator as a bucket full of usable IDs. If you leave ID
as NULL in the insert, then this trigger will reach into the bucket
and grab the next available ID.

If you want to get a new peopleid value, then you as the developer
make a rule that the value you use must come from the bucket. You can
use the select query I demonstrated before (useful if you are
maintaining a master-detail list). Of course it only takes one person
to break the rules and you will get PK violations.

>
> however, the code apparently referencing this trigger is the SQL

Insert

> statement which I had previously written: SQL.Add('Insert into

People (ID)

> values (0)');
>
> So, is this still causing the error in the same way thought

previously? (I

> presume it works in a multi -transactional envirnoment ?)
>

If that trigger was active then no, each ID would have been
different. Remember that check constraints are also implemented as
triggers. Your best bet is to find out what constraint INTEG_55
refers to by looking in the RDB$ system tables, then working out
which constraint exactly is being violated.

When defining constraints you should name them, then the error will
be meaningful.

Adam