>>>We have this client with 5 workstations on one site, and 5 on the other site, about a quarter of a mile away. They want the computers to talk to each other and are thinking of putting a cable in. I assume if they do that it will just work like a fileserver based LAN (is that true anyway?). However, suppose they didn't and it would have to go through the phone.. transporting data through phone lines is going to be slow I reckon, except for a Client / Server application. I'm very familiar with remote control with PC Anywhere, but I figure that only one computer at the time can have remote control. What about a gateway, or remote access service? I figure that they would have a LAN on each site, with one fileserver on one of the two sites and the non-fileserver site logs onto the fileserver.
>>>
>>>Can anybody help me out regarding this please with a solution that doesn't involve C/S (which we're working on but isn't quite ready).
>>>
>>>Thanks very much. Rene.
>>
>>Evaluate Citrix's WinFrame (www.citrix.com)...
>
>Thanks, I've looked at it and also gone through all the threads in this forum. Sounds mixed, but not bad. Am I right to think that this will replace or at least challenge C/S solutions in future?

Thin Client computing, whether Java NC's, Citrix WinFrame, or Windows Terminal Server (built into NT 5.0 using Citrix technology), will continue to grow. Citrix was thin client before Java NC became a hot topic, and although NC's have yet to really take off, WinFrame continues to grow in popularity and installed base. In fact, WinView (WinFrame's predecessor) began as an OS/2 server solution that provided thin client computing for DOS and Windows 3.1.

WinFrame would allow you to run existing FoxPro applications effectively for remote sites without converting data to a SQL Server backend. With WinFrame, only screen refreshes and print jobs are sent to the client workstation; all processing occurs on the WinFrame server. I think that the performance would surpass Client/Server in many instances. However, you could expect that a C/S solution based on WinFrame would also outperform a traditional WAN based C/S solution as the client processing occurs on the WinFrame server...

I had an initial problem with VFP on WinFrame 1.7 with the form refresh. However, after following advice from UT members to properly implement the LockScreen property of the form, I achieved screen refresh rates comparable with our in-house developed Delphi applications. Also, we run FoxPro for DOS on WinFrame without any problems, except that it must run in a DOS Window vs. Full Screen if the WinFrame Clients run on Win 95 and need to print locally.

I would definitely suggest that you evaluate it for your needs. You may find that you will not have to rewrite your existing apps...

Jack Mendenhall
Reinsurance Management, Inc.