Jim,

> I don't find batching as exciting as some other people do. Yes, it
> may reduce the number of round trips, but at the expense of
> application program complexity. If somebody want to explain why
> batching sql statements is the best thing since sliced bread, I'm
> all ears.

Maybe you're right. Let's compare the speed of the data inserts when
accessing Firebird running on localhost via TCP, IPC and in embedded
mode. I have not done comparisons recently, but from what I remember,
AS3AP suite gave approx. following numbers:

TCP - 100%
IPC - ~80%
embedded - ~50%

You can say that most of the time is lost in the TCP/IP stack, data
conversion, etc. I won't argue, but the result you see.

Even if you do not agree to abandon idea of returning status vector
for each statement (though I think we can do it), the idea remains the
same - bring as much data as near as possible to the disk. Idea is to
allow server to receive a chunk of data, feed it somehow to the
engine, collect responses, return them in a chunk to the user.

Sorry, I believe that 50% speed improvement on massive inserts or
updates are worth the additional complexity of the server/engine code.

Roman