Or a while loop that is massive, where the procedure does inserts in the
transaction and at the end of the loop
does a commit. Donnu but I believe this is also a possible cause.

Hope it helps


At 14:41 02/12/2003 +0200, you wrote:

>Sorry What I tried to say was
>
>Personal I believe your problem ,due to the LARGE transaction gap, is a
>procedure that gets called on a trigger that gets affected
>by a record change that the procedure
>itself creates.
>
>
>At 14:39 02/12/2003 +0200, you wrote:
>
> >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]
> >
> >
> >
> >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]
>
>
>
>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]