Craig wrote:
> For years my software has run quickly on a local drive but when there
are
> large files on network drives, it slows down terribly
> when moving from record to record.
Well, lots of folks here have fairly large apps/databases running across
LANs and WANs. I would start by looking at. For record to record
navigation, the file size shouldn't matter all that much. I'd take a look
at the code that fires on record navigation events.
Also, when you say "network" I suspect you have something a little more
involved than a simple LAN. Two things will rapidly kill network
performance for shared file access - bandwidth and latency. Chances are,
the only control you have over this involves the physical location of the
server in regard to the clients - you want to make sure that there are
very
few hops between them, preferably none.
You can get a sense of this by pinging a large packet from one of the
clients to the server and also by running a traceroute between one of the
clients and the server. The ping will tell you latency and the tracert
will
tell you how many hops.
You want to work with the IT folks to minimize latency and hops, which may
be as simple as plugging the server into a different local LAN segment.
The
benefit goes both ways -- if you can minimize the amount of your traffic
"pollutes" WAN circuits, everybody wins.
Whatever progress you make there, you also want to look at your code. You
want to minimize queries and unindexed filtering, particularly in record
nav
operations.
Ping:
ping -l 65500 <server DNS name>
Traceroute:
tracert <server DNS name>
--
Larry DiGiovanni
|
