Morning Maya,

>> 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. If you assume, as
many of my vendors do, that the application is the be-all and end-all
then this code wouldn't be there as the application handles all ids and
such like.

However, the person who designed the database and created that trigger
was thinking intelligently. s/he has protected against the times when a
script or an isql session attempts to insert a new support incident
without an id supplied. The code above has three main effects:

1. There will be an ID present when the record is INSERTed.

2. The ID will be "in sequence" with the application, so no chance of a
duplicate ID being used.

3. I've forgotten the third one. Need more coffee!

One thing it will not prevent though is the occasion when a
script/developer/dba supplies a value in the ID column for a new support
incident. The trigger code will see the value and not attempt to use the
sequence. That could cause troubles.

To avoid this latter case, the application should rely on the trigger
always supplying an ID and the trigger should check for INSERT
operations.

The above is my opinion others are available, as they say! ;-)

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

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

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