I thought about that that Is why I gave the second possible reason. The
main thing is for a client application to
create a million entries is massive, but doing this with Cache updates
means that the changes is made client side not server
side. Thus somehow this is uncommit items on the server side. The only
possible reason I can think of is a stored procedure that
can go at such a fast rate. But that is why I gave my second reason as I
thought about what you said after I posted it.


Hope it helps, Cheers going home


At 13:48 02/12/2003 +0100, you wrote:

>Johannes Pretorius schrieb:
>
> > 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.
>
>But which would still run inself the _SAME_ transaction context and
>would NOT create a new transaction for every update it handles since
>this is impossible.
>So this can't be the reason for the enormous gap.
>
>
>I think it's like Helen said: Something is happening on the client.
>
>Maybe there's a single connection (or sth. like that, for example a
>little program) surverying the database without ever doing any commit.
>
>Luc.
>
>
>
>
>
>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]