I would have to guess it is because of the session busy cursor. IBX doesn't
use a screen cursor (SQL hourglass) but IBO does. If you don't bracket long
running jobs (that have lots of iterations) in a BeginBusy/EndBusy block you
will get needless hourglass flicker going on.

Wrap your code something like this:

MyDSQL.BeginBusy( false );
try
...
finally
MyDSQL.EndBusy;
end;

Please let me know if this makes a difference. It is so second hand to me
now to do this that I forget to think others are not doing likewise.

Making sure the IBO transaction isn't in AutoCommit = true would be another
check. No point in doing a commit for each record (unless you are required
to).

PS. I thought you were using a TIB_Script to start with and I wasn't talking
about any optimizations but rather my parser being potentially more
computationally intensive than the IBX's script equivalent.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Jason Frey" <jason_frey@...>
To: <IBObjects@yahoogroups.com>
Sent: Friday, June 07, 2002 4:08 PM
Subject: Re: [IBO] Newbie Question -- Inserts slow?


> > Have you tried using TIB_DSQL or TIB_Script? With TIB_Script, you could
> > load all of the file into it and execute it. Also, make sure your
> database
> > file extension is not ".gdb", WinXP monitors these files for the system
> > restore.
>
> No, I hadn't tried either of those, although after looking again at the
> descriptions, TIB_DSQL was what I should have been using, rather than
> TIB_Cursor. I re-ran my tests using TIB_DSQL, and performance did jump,
but
> I'm still getting 60% of the performance or so that I was getting out of
IBX
> (On this mass insert operation.. I haven't run benchmarks of my own beyond
> that). I didn't want to try TIB_Script, because I wanted to try and get
as
> close to an apples-to-apples comparison as I could.
> I know about the gdb thing, and it's not an issue. Even if it were, since
> the tests for both IBX and IBO were run on the same machine, logic would
say
> (to me) that the slowdowns due to System Restore would apply to both
tests,
> hence not be a factor in the final outcome (Other than, "Gee, both of
these
> insert scripts are slow", which isn't what happened).
> Jason's comment about the optimizations being more complete in IBO could
> very well be what my slowdowns are because of... I can't think it's
because
> of the inserts themselves being particularly complex. :) Which points to
> something under the hood. that's going on, before the statement makes it
to
> the server. The processor usage difference between the two transaction
> commital styles (Committing after every insert, or committing after every
> 15,000 inserts) also bears that out, to an extent.
>
> - Jason