Artur Anjos wrote:

>Hi Jonathan,
>
>>1) Why does preparation of a query require a lot of communication over
>>the wire (which makes it the slowest of part of executing a query over a
>>slow connection)?
>>Everyone so far has simply told me that since it's a server-side
>>operation, it shouldn't be affected by the speed of the network
>>connection. I fully agree, but unfortunately, my experience shows that
>>in practice, this is not the case. Has this been fixed in FireBird 1.5 ?
>>
>>
>
>Yes, that's the big problem. This couldn't be solved without changing the
>protocol,
>

Of course.

>so you will not see any improvement on Firebird 1.5,
>

I see.

>just in 2.0.
>Dmitry already implemented a new protocol in version 2.0.
>

Excellent!!!

>>2) Are there any plans for integrating an on the fly data
>>compression/encryption system (like Zebedee) into FireBird? (snip)
>>
>>
>
>No. It was discussed to use some kind of plug-ins in the future, but I think
>you will not see it in version 2.0.
>The global opinion is that you can use another product to do this job, so
>let the people who know about that data compression/encryption (like
>ZeBeDee) do there job. :-)
>I know it will be more simple, but I think this aproach it's more flexible.
>If you are on fast networks you will not need this in 90% of the cases.
>
>

Ok. Fair enough. I guess it no big deal to use Zebedee.

>>3) Have there been / are there going to be any improvements in the
>>communication protocol itself in order to eliminate unnecessary chatter
>>(for example, sending varchars with trailing spaces)? I've heard that
>>there had been some work done in this direction in Interbase 6.5.
>>
>>
>
>"Sending varchars with trailing spaces" was fixed already in version 1.5
>

Very good.

>(it
>was a client problem, so maybe you can try - at your own risk - to use fb
>client 1.5 with 1.0 server, since the client should be backward compatible).
>

I'm not prepared to take the risk. I used to have a performance problem
for one of my customers, but I've now implemented a replicator, so this
problem is not very significant, as only the replicator ever uses the
direct connection to the main database. Still, for future projects, it
would be nice to have better performance over slow lines.

>I hope this helps,
>

Sure!

Thanks a lot!

Jonathan Neve.


[Non-text portions of this message have been removed]