At 05:54 PM 13/03/2006, you wrote:

> > >There is a trigger for the addition of a new Person to the People Table
> > as
> > >folows:
> > >
> > >CREATE TRIGGER NEWPERSONTRIGGER FOR PEOPLE
> > >ACTIVE AFTER INSERT POSITION 0
> > >AS BEGIN
> > > EXECUTE PROCEDURE NewPerson(NEW.ID);
> > > END ^
> >
> > You don't tell us what the procedure NewPerson(NEW.ID) is
> > doing....what table the procedure acts upon....but the person who
> > wrote this has made a mistake if he thought this would generate a key
> > value for a newly inserted record in PEOPLE. An AFTER INSERT trigger
> > cannot assign any values to the NEW.* context variables.
> >
> > So, this is probably the source of the key violation errors. Show us
> > the content of this trigger.
>
>
>
>ALTER PROCEDURE NEWPERSON (PERSONID SMALLINT)
>AS
>BEGIN
> Insert into ContactDetails (PersonID)
> values (:PersonID);
>END ^
>
>I believe that is the procedure that the Trigger calls.

This should be OK as an After Insert trigger, since it involves a
different table.

However, you have to check those two constraints and find out which
constraints are getting violated. If it turns out that one (or both)
is on ContactDetails, then you will know that the PersonID value
getting passed to this procedure already exists in
ContactDetails. The solution to *that* problem would be simple:

ALTER PROCEDURE NEWPERSON (PERSONID SMALLINT)
AS
BEGIN
if (exists (select 1 from ContactDetails
where PersonID = :PersonID)) then
Exit;
else
Insert into ContactDetails (PersonID)
values (:PersonID);
END ^

But you will have no idea which table's constraints are being
violated until you explore the actual constraint definitions. At
least you will then be able to figure out whether it is the
application code or something in the database that is making these
errors happen.

./heLen