Report speed over VPN issue

[Jay]

Steve,
I have a similar situation with a client of mine.  Also running filePro in a
mixed Windows (XP & 98 clients) environment on the local desktops (on a
Novell Netware network).  I have the filePro data files on a mapped drive,
pointing to the Novell server, and the clients each have the EXE's (dclerk,
dreport, etc) on their local desktops.  filePro environment variables are
all in a local batch file that's called when the desktop icon is executed.

I've setup the local firewall with a NAT policy to allow Terminal Services
from a PUBLIC IP address directly to the user's client.  This way, from any
remote location (a branch office, their home, an air card, or a wireless
hotspot) all they need is an onramp to the internet, and with Remote Desktop
(built into the XP operating system) the remote user simply needs the IP
address and the local login credentials.  Remote Desktop is also available
for 98, but it's not built into the OS; it is downloadable from Microsoft's
website.  

To access Remote Desktop, you can either navigate to it...ALL PROGRAMS->>
ACCESSORIES->> COMMUNICATIONS->> REMOTE DESKTOP CONNECTION, -OR-
RUN->>mstsc. The same scenario will work over their VPN, but they sacrifice
speed.  On the VPN, once the connection is established, they'll need the
LOCAL IP address of the client machine rather than the PUBLIC IP address.

To view reports, add -pv to the command line in the menu entry.  To print
locally, add -pt to the command line instead of -pv.  

In my example client, the company's controller needs to do the same
thing...view first, then either save the file for future reference, or print
it remotely.  I copied the default menus & modified all of the menu entries
to be batch/script files with "-p \tmp\fpreports\$REPORT" in the command
line, and defined $REPORT to a user-friendly name with a ".txt" extension.
After generating the report to a file, I followed the dreport line with
"type $REPORT | more" so the user is put right into a view mode of the
report just generated.  With a little training (and the user knowing that
telecommuting allowed her greater work & time efficiencies as well as a big
savings on gas & tolls), she saves the report to a default folder on her
desktop and emails it to herself, then prints the report to the printer
connected to the remote machine.

While this all may sound a bit detail intensive, it took me about an hour to
set it up for the company's controller, and about 20 minutes to train her
how to use it.  

The nice thing about Remote Desktop is that you can modify the online
options to eliminate the caching of desktop bitmaps and some of the
graphic-intensive items on the desktop.  On pcAnywhere, you don't get that
option & end up sacrificing the Windows GUI for speed.  I've found that most
power-users are more interested in speed than the bells & whistles that the
graphics display.

Hope this helps.

Jay Kantrowitz

> Steve Wiltsie <swiltsie at micro-mui.com> wrote:
> 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)