Good day
\=-\=\=-\==-
What I can suggest is to try and first see if this is a select that comes
from the client side
or a stored procedure that gets called, from trigger or client app, but is
not program code related.

Personal I believe your problem due to the LARGE transaction gap, is a
procedure that gets
called on trigger that gets affected by a record change the the procedure
itself creates. But this
is theory and if I remember correctly Interbase checks for this. But I
believe it is something related
to this.

First ask the clients that when the system goes slow not to close (kill)
the application and try again.

Then when the server starts using CPU try running netstat in a console
window and see what machines is
connected to the gds_db port. This gives a smaller group of machines to
check for the slowness than your original 100.

Setup a questionare for these client machines users on what they where busy
with when it became slow, this will give you a Idea
of which ones is out of the question and those that is questionable.

Now Delphi 5 had a SQL Monitor program, I believe you will also have.
On these machines that is questionable start with them and configure the
program to log to file for 500 kb.
then run the program before you start your client program, THIS WILL make
the program slower and create POSSIBLE BDE ERRORS if running
for a period of time, thus you might want to do
this in small groups. Now if it goes slow again. Ask the questionaire again
and see if there is common step as in the previous answers and see these
machines
log files for futher answers on what was done.

In short, if this is a query that is run, for instance we had a search
screen where the select get's build depending on what the criteria was and
in some cases
they had a invalid join that created a UNBELIEVABLE result. then you will
pick it up. If it is a stored procedure then you will have to look more
into that.

I hope this helps, I am also in the same industry as you (Radiology) and
have had the
same issue and the only solution was following the above steps to get the
solution.

Hope it helps

Johannes



At 11:23 02/12/2003 +0000, you wrote:

>The app uses the BDE to connect to the database and do its work.
>
>We call TDabase.Commit inside a try except block, the exception handles
>calling Tdatabase.Rollback.
>
>I am not too sure what you mean by autocommit and hard commits.
>
>The databases have forced writes enabled, and we seem to handle
>ApplyUpdates, CommitUpdates in the Tquery objects, then call a
>Tdatabase.Commit.
>
>Is there something else we should be doing, if so please please please
>tell me as my customers are also rather annoyed with having to be taken
>down (they are 24/7 medical operations) to backup and restore....
>
>Thanks for any help..
>
>-----Original Message-----
>From: Helen Borrie [mailto:helebor@...]
>Sent: 02 December 2003 11:16
>To: firebird-support@yahoogroups.com
>Subject: RE: [firebird-support] Who's guilty?
>
>At 09:36 AM 2/12/2003 +0000, you wrote:
> > I have similar issues with some of my sites using IB5.6 and
> >IB6.0.2.0, I cannot replicate this in my test rig, and I have checked
> >my commiting code numerous times to make sure I am always calling
> >either a .commit or a .rollback ,
>
>I suppose you do understand that, if commit fails, your application will
>have to handle the failure...
>
>..and that Autocommit prevents the record versions from the involved
>transactions from being made "uninteresting"...
>
> >but I get I huge gaps in transaction statistics, I cannot do a sweep as
>
> >the gap is not between the OIT and OAT (see example) so my only option
> >is a backup and restore. I have tried IB_AFFINITY to set it to one
> >processor in the dual processor machine, I have also had the IT team
> >turn off hyperthreading in the bios, all to no avail.
> >
> >OT 566738
> >OAT 566739
> >NT 940551
> >OS 564916
> >
> >After checking this weekend the OT,OAT and OS have not moved from
> >above, but the NT is now more than a gap of 1 million to these other
>stats..
>
>1 million Autocommits and no hard commits?
>
>/heLen
>
>
>
>
>To unsubscribe from this group, send an email to:
>firebird-support-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to
>http://docs.yahoo.com/info/terms/
>
>
>
>
>
>
>To unsubscribe from this group, send an email to:
>firebird-support-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.545 / Virus Database: 339 - Release Date: 27/11/2003

----------


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.545 / Virus Database: 339 - Release Date: 27/11/2003


[Non-text portions of this message have been removed]