I actually have apps running over the Internet accessing a DBISAMServer over a VPN.
Performance is "acceptably fine". However, I am embarrassed and a bit confused about the
use of DBISAM Server over a LAN. I was under the impression that, with the proper tuning,
there might be a benefit to an entirely local application using Server/Remote Access over
a LAN. I actually seem to recall a property in the V.3 server that could be set to stLAN
or stRemote that would control compression. However, after some testing, it seems to me
that local access pretty well dominates C/S access; i.e. there can never be an advantage
to using the DBServer in a local application.

Again, I'm embarrassed because this might be common knowledge but extensive reading of the
manuals/tips and experimentation has left me totally confused. Is there an easy answer?

Thanks for any pointers.


=NLK=

Norman,

<< I actually have apps running over the Internet accessing a DBISAMServer
over a VPN. Performance is "acceptably fine". However, I am embarrassed and
a bit confused about the use of DBISAM Server over a LAN. I was under the
impression that, with the proper tuning, there might be a benefit to an
entirely local application using Server/Remote Access over a LAN. I actually
seem to recall a property in the V.3 server that could be set to stLAN
or stRemote that would control compression. However, after some testing, it
seems to methat local access pretty well dominates C/S access; i.e. there
can never be an advantage to using the DBServer in a local application. >>

The key with C/S access is to reduce the amount of network latency by
limiting the number of round-trips to and from the database server.   If you
could perhaps give me a little more information on the type of code that
you're having performance issues with, I can give you specific information
on how to optimize it.  Usually the optimization involves simply moving any
batch processes to the server via server-side procedures.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Norman,

-snip-

The key with C/S access is to reduce the amount of network latency by
limiting the number of round-trips to and from the database server.   If you
could perhaps give me a little more information on the type of code that
you're having performance issues with, I can give you specific information
on how to optimize it.  Usually the optimization involves simply moving any
batch processes to the server via server-side procedures.

--
Tim Young
Elevate Software
www.elevatesoft.com
---------------------------------------------------------------------------------------
Tim:

Well I've got LOADS of lookup lists (implemented as queries) for one thing and a large
dataset that gets loaded into a grid at startup. The lookups also need to be filtered in
various ways. I guess the best way to handle these is to cache the lookups locally, which
I can do, and also use the trick of NOT loading all records at startup but ask the user to
restrict by date/ID#. I can also try different remote readsizes, etc. I've experimented
with these modifications and of course they DO speed things up; however, with all these
machinations I merely APPROACH the speed I would get by using direct LAN access.

I know there are numerous posts on this NG regarding speeding things up when using the
Server and I understand that if you are accessing records via TCP/IP then it's mandatory.
However, I'm not sure whether or not some subset of those tips (or information in the
manual, etc.) relates to local LAN use.

If you have pointers to those kinds or resources I'd appreciate it. I'd love to be able to
tell my LAN only users that a server would help with data access speed.

Thanks for responding to my post, Tim. I know your time is limited.


Norman

Norman,

<< Well I've got LOADS of lookup lists (implemented as queries) for one
thing and a large dataset that gets loaded into a grid at startup. The
lookups also need to be filtered in various ways. I guess the best way to
handle these is to cache the lookups locally, which I can do, and also use
the trick of NOT loading all records at startup but ask the user to restrict
by date/ID#. I can also try different remote readsizes, etc. I've
experimented with these modifications and of course they DO speed things up;
however, with all these machinations I merely APPROACH the speed I would get
by using direct LAN access. >>

Lookups are a particularly thorny issue because the way that Delphi has
implemented them.  You should definitely load the lookup lists at startup if
you can get away with it.   Setting RemoteReadSize to a value larger than
the lookup table row count will result in the entire lookup table being
pulled in one shot.  Or you could simply use a
RemoteTable.SaveToStream/LocalTable.LoadFromStream design to pull across the
lookup tables.

<<  I know there are numerous posts on this NG regarding speeding things up
when using the Server and I understand that if you are accessing records via
TCP/IP then it's mandatory. However, I'm not sure whether or not some subset
of those tips (or information in the manual, etc.) relates to local LAN use.
>>

Yes, they apply to any time you are using a remote session to access a
DBISAM database server.

--
Tim Young
Elevate Software
www.elevatesoft.com