Morning Maya,

<SNIP>

>> Yeah, I was thinking about that while eating breakfast -

I remember when I used to have time for 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.

It's a shame that the other tables don't have it, it would protect all
your data.

<SNIP>

>> 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.

Sounds remarkably like a new "feature" in 2.5 then. Especially if it
goes away when you revert.

<SNIP>

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

No, this is not how a deadlock should behave. It should raise an
exception in one of the two transactions that are blocking each other
which should be handled appropriately by the application. The entire
database should not be locked up.

<SNIP>

>> 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.

In which case, it sounds remarkably like this is not a deadlock.

>> >> 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.

Have you tried isql directly on the database server?

<SNIP>

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

I'd almost put money on it not being a deadlock. At least, not in the
normal sense of the word as applied to the application. Maybe something
internal is deadlocking (if that's at all possible?) - such as
attempting to create/use a new database page for an index or data page
or similar?

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

Perhaps. I'd say that if the application is handling all possible
exceptions and you are not seeing any, there is most likely something
systemwise going wrong. (Best guess!)

>> 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.

It's not a deadlock then!

>> 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.

Good luck.

<SNIP>

>> Thank you for your ideas ;-)

Welcome.

Cheers,
Norm. (at work!)

Norman Dunbar
Contract Senior Oracle DBA
Capgemini Database Team (EA)
Internal : 7 28 2051
External : 0113 231 2051


Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else.

We have checked this email and its attachments for viruses. But you should still check any attachment before opening it.
We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes.

If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk