Subject | Re: Fetch multiple rows using isc_dsql_fetch |
---|---|
Author | Adam |
Post date | 2006-02-26T23:47:41Z |
--- In firebird-support@yahoogroups.com, "kapsee" <kapil.surlaker@...>
wrote:
would first look for some sort of fetch all call. (It may not exist).
If it doesn't exist, then you have a service running on the database
server that your application talks to. That service then queries the
database with only a tiny latency (127.0.0.1), and returns all the data
to your application in one hit. Don't reinvent the wheel though. I am
sure there will exist a product that wraps the TCP connection stuff in
your programming language, most of which have compression built in are
great for this sort of thing. We use RemObjects (with Delphi) to do
similar tasks, although latency was never really an issue for us, a
direct connection to the database from a remote site was not acceptable
from a security standpoint. Even with a VPN, it is nice to have that
extra buffer between their database and the bad guys.
Adam
wrote:
>I use components that wrap the API rather than the API itself, but I
> isc_dsql_fetches only a single row at a time. Does this require a new
> round trip to the database for every row ? My application communicates
> with the database over a high latency connection and I need to
> minimize the number of round trips by fetching as many rows as
> possible over a single round trip to the database. How do I optimize
> this ?
would first look for some sort of fetch all call. (It may not exist).
If it doesn't exist, then you have a service running on the database
server that your application talks to. That service then queries the
database with only a tiny latency (127.0.0.1), and returns all the data
to your application in one hit. Don't reinvent the wheel though. I am
sure there will exist a product that wraps the TCP connection stuff in
your programming language, most of which have compression built in are
great for this sort of thing. We use RemObjects (with Delphi) to do
similar tasks, although latency was never really an issue for us, a
direct connection to the database from a remote site was not acceptable
from a security standpoint. Even with a VPN, it is nice to have that
extra buffer between their database and the bad guys.
Adam