>> >>And this on insertion of new support incidents:
>
>> >> IF (NEW.ID IS NULL) THEN
> >> NEW.ID = GEN_ID(GEN_CUSTOMERINCIDENTS_ID,0);
>
>> >Should be
>> >IF (NEW.ID IS NULL) THEN
>> > NEW.ID = GEN_ID(GEN_CUSTOMERINCIDENTS_ID,1);
>
>> Thanks everyone, I think this just confirms the code never gets executed. I will correct it ASAP. I don't think it will affect the FB2.5 hanging issue though, as it's not inserting into that table that's hanging, it's the other table.

>Be careful, this might just be 'valid' code. Think of a 2 table setup where there is a one-to-one relationship. Table A gets the ID from the generator, incrementing it, Table B inserts using the same ID to link to table A.

Of course this would be dangerous in a multi-user situation and depends on the insertion sequence, but if the operattions on table A are serialized it might just work without causing any problems.

Your suspicions are correct (in that this code was actually meant to have a zero), although not quite what you thought.

I modified the zero to a one, but then I started getting reports from staff of errors.

The Communications table for this incident, was complaining that the IncidentID was invalid (because of the foreign key relationship that I'd thankfully put in there)

So, it seems that this code IS getting used , BUT it is getting incremented elsewhere.

Looks like a whole can of worms.... but at least if I ever get weird incident numbers for a comm, I'll know where to start looking...

PS. for the rest of my problem, it seems I just need to try Fb 2.5.1. Will burn some mid-night oil soon while everyone's off line, and let you know the results.