Hi Ken,

I had read an article 'A poor man's server' and learnt from it. I tried it, it worked well but I have not yet used it in any of my applications.






> > > > > > goingtothetop
> > > > > >
> > > > > > I have a fleet management program that the owner would like to implement across towns.
> > > > > >
> > > > > > I have done the program using the Project Manager.
> > > > > >
> > > > > > Currently, we have installed on the first town-& it is ok.
> > > > > >
> > > > > > Upon getting the network connection equipment - the router etc what am i supposed to do?
> > > > >
> > > > >
> > > > > Is Town 2 supposed to connect to the data of Town 1? Is this a VFP database? If yes, then I suggest you setup a single windows Terminal Server and install your app on that server. The clients from Town 2 can connect to the TS with the Remote Desktop Client.
> > > > > --
> > > > > Eric den Doop
> > > > > www.foxite.com - The Home Of The Visual FoxPro Experts
> > > >
> > > > Another option, (not to be contrary! heheh) if one of the locations has a static IP address for their internet connection, is simply to buy a $60 VPN-capable router for each office, and have the one at the office where the data/server is host a connection. It is as if all computers at all offices connected this way are on the same LAN.
> > > > (I.E. if you are sitting at a computer named "Jim" and at the other office is a computer named "Workstation", the user at JIM can actually >PING WORKSTATION and get a reply. By extenstion, they can connect to the server the data is on as if it was at thair office).
> > > > Also, if the main office is running windows 2000 server anywhere, they don't need the router at that office. Just host the VPN with win2k server, and have the VPN capable routers at the other locations maintain a connection to it.
> > > >
> > > > The advantage to this is that, local data can be stored more easily on the user's machine, rather than in the Remote Desktop profile.
> > > >
> > > > Duffy W.
> > >
> > > Duffy,
> > >
> > > This will work - in fact I use this now between our Springhill and Halifax offices. One thing to remember though - this is going to be a VERY slow connection. If Elijah is going to do this, it may require some substantial changes to his code.
> > >
> > > Ken
> > > You shall know the truth - and the truth shall set you free. (John 8:33)
> >
> > True. I'm used to having corporate clients with large bandwidth pipes and fast connections (I.E. 5-8 Mbps). Usually with the client app on the local computer, but I've done it with the client program on the remote machine before, and it seems to work alright, as long as you don't get too fancy. If the EXE file is under 2 to 5 megs, and the DLL's are all on the local machine, it's not too bad at all. It isn't quite like being on a 10-baseT lan, but for smaller apps, it works sooooo nicely. = )
> >
> > Cheers!
> >
> > Duffy W.
>
> The real problem here is when you attempt to look at a large table. For example, lets say you have a table with 1,000,000+ records. You issue a command like:
>
>

> SELECT Fld1, Fld2, Fld3 FROM MyTable WHERE SomeField = SomeValue INTO CURSOR MyCursor
> 

> Lets also assume that the WERE clause will result in 50 or 60 records being selected. We know that it would not take long to download the 50-60 records each with only three fields. The problem is the WHERE clause. Where does the filter get applied. Unfortunately, with a VFP back end, the WHERE clause gets evaluated at the client computer. Now, if you were using SQL as the back end, the WHERE clause would get evaluated at the server and only the result cursor would be downloaded to the client. This is why you pretty much have to build your own vfp server. There are VFP servers available for download on the Internet but I have yet to find time to play with them.
>
> Ken
> You shall know the truth - and the truth shall set you free. (John 8:33)