Hi Ann,

>>>> IF (NEW.ID IS NULL) THEN
>>>> NEW.ID = GEN_ID(GEN_CUSTOMERINCIDENTS_ID,0);
>>>>
> ...
>>
>> 1. There will be an ID present when the record is INSERTed.
>
> That may be true, but the primary key index will reject a null primary key, so
> a record with no ID will never be inserted.

Well, that's obviously true, *assuming* that the table was defined with
a PK on the ID column. As we weren't told that this is the case, best
not to assume. ;-)

However, I didn't spot the zero on the end of the gen_id() function
call. My bad. I read it as a digit one for some reason - possibly
because that was what I expected to read. (And I wasn't the only one!)

>> 2. The ID will be "in sequence" with the application, so no chance of a
>> duplicate ID being used.
>
> That depends entirely on how keys are generated in the normal case. Unless
> they always use the same generator, that trigger could easily create duplicates.

Agreed. As I mentioned, I missed the zero!

<SNIP>

>> I would assume this to be the case. But as you said earlier, you are on
>> 2.5 and there are a couple of "complaints" about 2.5 on this list at the
>> moment. If there is a 2.5 problem, maybe you are hitting it.
>
> It may be a 2.5 issue, or it may be a huge number of unsuccessful retries.

Again, true. However, I'm not using and abusing 2.5 much yet, so I
didn't want to cast aspersions on it's good name! Not without hard
evidence first. In my day job, it's almsot always the application
causing trouble, not the database. About 99.9% of my "database" troubles
are in fact application troubles.


Cheers,
Norm.

--
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767