Report speed over VPN issue

[Fairlight]

With neither thought nor caution, Steve Wiltsie blurted:
> 
> The problem is that the wireless notebook needs to access the network via a
> mapped drive - not PC Anywhere.  This works but is pretty slow for menu and
> screen functions.  The real problem is in generating reports to view or
> print.  A report that would have been ready in a couple of minutes is still
> selecting records an hour later!!!  I tried it with the filePro programs
> installed on the notebook and didn't see any increase in speed.  How can I
> get the reports to prepare faster over this VPN link with the existing
> hardware/software?
> (Switching operating systems is not an option)

Do I understand correctly that you're actually trying to use PFDIR, for
example, set to a location on the internal server, and accessing it with
filePro on the remote client?

-IF- that's the case, I don't think anything will help your performance
issues.  In the case of file operations, you're basically telling CIFS/SMB
to use this file, and/or parts of it, from remote.  For adding a record,
this isn't a huge deal, as you have pointers and the like to the locations
in the freechain, etc.  It can do seeks.

But when you start doing a report, please realise that if the application
needs to scan through the records, it has to first go through the index
file (probably in its entirety), which means transmitting the whole lot up.
Then it needs whatever parts of the key/data segments are indicated by the
index scan selection, which is yet -more- data transmission.  If you have a
several hundred megabyte table, I can see where you're hitting some speed
issues under this topography.  Building an index should be slow as molasses
as well, as it has to scan the whole bloody data/key pair (and any extents
that may exist, although they seem to have fallen into obscurity) -and-
write back the new index.

And I don't see a thing for it.  There's no real fix if you have to access
it as a mapped drive.  fP-Tech isn't at fault, and neither is the OS.  It's
simply a flat reality of the topography and the requested functionality.
Assuming I got the correct gist of what's going on, nothing short of
changing the topography will fix the performance.  Changing OS isn't even
an issue in a case like this.  You'd have the same problems trying to do it
with NFS and *unix, excepting that NFS is a bit faster.  But NFS is also
meant to be done on nothing less than 10mbit, although it -will- do it
slowly on less.  The OS and actual sharing protocol don't have anything to
do with its overall inefficiency.  It's the fact that so much needs to be
shared in general.

mark->
-- 
There is no "I" in TEAM.
This would be the primary reason I've chosen not to join one.