At 08:46 PM 28-08-01 -0300, C R Zamana wrote:

> > Check that you are preparing an INSERT statement, and then simply
> > assigning parameters for each row inside a loop. You are probably
> > having the server recompile each statements, this would explain a
> > lot of your performance problems.
>
> No, there is no preparation. The question is that the
>application was linked with a library that was made to be
>very generic.
>
> Each operation is independent of the others.
>
> I know that this is not the best approach for a batch process. But the
>question is that this same "approach" works very well with Oracle,
>without any tunning.
>
>Linux, RedHat 6.2, AMD Athlon 1Ghz, 128RAM, SuperServer
>( FireBird 1.0.0-0aBeta2 ).
>
> Is running on the server.

There was a problem with the "loopback" for local access to SS on Linux, i.e. the connect time was (is?) horribly long (several minutes). Ann may recall more about this...

Is it possible that your app is going through the connect process for *every* row? Since the performance you describe is absolutely absurd, it has to be something like this.

And if something like this is forced by your application, then the client is being asked to get a fresh transaction handle for every insert.

Have tried connecting to LOCALHOST instead of the local connect?

No solutions, just more puzzlement, as you seem to have managed to develop a world-record slow InterBase app <g>. 3500 * 300Kb inserts should be sub-second.

Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________