Hello Denise,
T1 can be regarded as very high bandwidth - however, it soon disappears when some plebian type decides to practise his kule (sic) multimedia skills, or you've loads of Users, or the Users are into moving large files, or ...

As suggested by others you can improve start-up response times by moving the executable onto the local disk of the remote PC's. If you do this and you have an application that gets upgraded occasionally, then you should consider using a loader.exe that automatically copies new versions from the central server -this is covered in the Files Section.

Knowing what kind of server is being used helps tremendously - the majority of UT knowledge base is Windows oriented, if the server is Unix or Novel NetWare then we can discount using quite a few of the options below and also any Win32 routines.

Before researching any of the suggestions below, you should make sure that your current SQL selects do not have any fundamental flaws. This is best achieved by copying the 'real' data set and Exe to your own computer and executing the sql selects without any network overhead - if instead of completing in seconds they
take tens of minutes, then it may be reasonable to assume that your queries are not fully optimized. Call SYS( 3054, 1 ) before your SQL select statement to determine the optimization level. You should also ensure that result sets are not excessive. Also as a general rule where performance is an issue, you should analyze your code using the coverage profiler. When you know for sure that the application, indexes, etc. are not at fault, then you should start looking at the alternatives suggested below.

Also, please note that the list below is not comprehensive. Less than two years ago I allowed several users in the U.S. and Asia access to a FoxPro 2 for DOS application running on DOS boxes in London using PC-Anywhere. The London side of the link was entirely DOS based, which meant no Windows GUI type infomation was transmitted over the link, thus minimizing demand for bandwidth. This was a reliable and pragmatic solution that cost very little to set up and maintain.

The following can be divided into two strategies: those that require special processing to wrap and unwrap the result sets, and those that do not. SQL Backend and DCOM, do not require any special code to wrap and unwrap the result sets. The roll-your-own solution could select into a temporary table on the server and then return the name of the file - this obviously introduces both cleaning up and multi-user issues. The following looked much better as a table but the UT did not like it?

Roll your own Fox solution
Pro's  Low cost, no learning curve, leverage existing Fox skills.
       Can be used for Unix and NetWare Servers if Fox Server Exe is
       running on a PC connected to LAN.
Con's  Not the most elegant solution. Requires a Fox Server Exe
       (processing requests) to be running either on the server or on a
       PC on the LAN.
       If the Fox Server Exe stops (crashes) then all clients are
       adversely effected immediately.

MSMQ (MS Message Queue)
Pro's  Very flexible, reasonably reliable and reasonably scaleable.
       Fox can be used on both front and back end. Modest learning
       curve.
Con's  Requires Server to be Windows. Also requires a Fox Exe to be
       running on the server to process requests - same downside as
       first option.

DCOM
Pro's  Modest learning curve, leverage existing Fox skills.
Con's  Both Client and Server platforms need to be Microsoft Windows.

HTTP
Pro's  Probably the most manageable in the event of large scaling-up
       Modest learning curve. Several implementation strategies (ASP,
       FoxISAPI, WestWind, etc.)
Con's  It helps if Server is Microsoft Windows. Server needs to be
       running a Web Server that supports one of: (ASP, FoxISAPI,
       WestWind, etc.) Note: The Web Server could actually be hosted on
       NT4 Workstation or Win2K Pro.

SQL Backend
Pro's  Very robust, very scaleable, etc.
       Multiple options: Oracle, Sybase, SQL Server, etc
Con's  (probably) the most expensive option. Biggest learning curve. Not
       an overnight fix. No point in half measures - meaning major
       application re-engineering.

Hope this helps,
Regards,
Houston.

>>In order to give you a better answer it would be useful to know how you are accessing the
>data at the moment
>
>Very right. And now that I have some specific questions my poor little brain that doesn't
>understand this as well as I wish I did can provide some hopefully helpful information :)
>
>does the application USE the remote Dbf?
>
>it's not a remote dbf. As far as I understand the system (and I just got put on this project
>so this is to the best of my knowledge) the exe and the dbfs are in the same place, in the
>same project and are not remote to each other. However, the user is about 2 hours away
>from the data and the exe. And they run the exe and the data from that server that they
>are 2 hours away from.
>
> is it via a mapped drive?
>I would think it is a mapped drive, but I'm not sure.
>
>>- what is the server (Novel, Windows NT4, Win2k, etc.)
>Completely don't know but I can find out. Can you tell me what difference this would make
>so I can tell the client when he asks (as I know he will)?
>
>>- what kind of connection is being used:
>> - High Bandwith Leased line, or
>> - crumby dial-up link.
>The client mentioned yesterday that they're using a T1, so that would be high bandwidth, right?
>
>In general, the more info you can give us, the more likely you are to receive good advice!
>Agreed 100%. Just wish I knew enough about how all this fits together to be able to give
>this information without being prompted for it. But I guess we all have to start somewhere.
>When I first found UT I was just starting with Fox programming. Now I guess I'm getting
>away from the "bologna and cheese" and into some of the spicier entrees :) :)