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]