Hi Norm,

>> And this on insertion of new support incidents:
>>
>> IF (NEW.ID IS NULL) THEN
>> NEW.ID = GEN_ID(GEN_CUSTOMERINCIDENTS_ID,0);
>>
>> (Which the person who originally wrote the app put in there,
>> which I'm not so sure it's even needed...the FIBPlus
>> component should be handling this AFAIK)

>This is most likely for data protection and integrity.

Yeah, I was thinking about that while eating breakfast - it'll probably be best to leave it alone. The other tables don't have it, but there was probably an odd situations where it was required, and made a certain function easier to program.

>> I think the next thing I'll try though, after setting up a
>> dummy server (if the problem persists on the other server),
>> will be to restore the database, to get it onto the new ODS,
>> and see if that changes anything.
>If the problem is a deadlock, I don't think a new ODS will help much.
>Deadlocks are almost always application generated.

The thing is, on all the other versions of Firebird I have used in the past (Firebird 1.5.4, 1.5.5, 2.1.3, 2.1.4 and 2.1.5 ) I have never had this problem.
ALL I am doing is updating the server version to 2.5, nothing else. And reverting to 2.1 goes back to normal again.

How can I be sure it IS a deadlock? Is the how deadlocks behave? Locking up the ENTIRE database?

>> BTW, I use no_wait for all my transactions, so I usually get
>> a deadlock exception rather than a hang.
>What does the application do when it gets a deadlock exception? Does it
>rollback and try again? Is it possible that more than two transactions
>are involved and the deadlock is actually, a deadly embrace?

It rolls back the transaction, and re-raises the exception, so the end user see's the message. No message is being seen by either of the users.

>> It's also so locked up, I can't get into the database at all.
>When you try, and fail to get in, does the firebird.log tell you

anything useful?
If I try open via IBExpert it just hangs.

>> If it was just a deadlock, surely I should be able to at least get to

the

>> monitoring tables? And into other tables in the database that are not
>> locked up?
>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.

If it is a deadlock, then it's a deadlock that's happening on FB 2.5, and NOT happening on FB 2.1

And which isn't looking at my no_wait settings. So maybe something very low level. A system table perhaps...

BTW, it's not a concurrency thing. I don't have to create the 2 records simultaneously, user B just has to have inserted into that table at some stage, then when user A tries again later - HANG.

I think what I must do as well when I have the dummy test server set up, it to try add the record via IBExpert. That way I'll be able to tell if it's just something in about that table, or whether some of the weird and wonderful complicated refresh code, or one of the data aware editing components in the application is causing the problem.

Thank you for your ideas ;-)

Maya