this is exactally the type of application I am working now. after doing some testing. I found that it works great. ! Its a little different to program that way. and you do have look out how many records you download.

two types of commands you could send, the easy way (most restritive) using remote views.

and sqlexec. where you send the actual sql commands to the server, and get back cursors. - you can do anything with that. its takes more time this way. but once you get it. you have more flexability that way.

the remote views dont like it too much is you change something on the server side. so It would be better I assume if you already have a database on a server already set up and running. and all you are doing is getting data from it. but if you are starting with constructing the sql server, then setting a remote view....well if you change something one the structure of the server, you have to recreate the remote view...

Bob Lee

>The other day, someone asked me a question that partly stumped me.
>
>Basically, suppose someone had a front-end written in VFP that accessed SQL Server tables. The front-end was running on a client's laptop, the SQL Server database was running at a corporate location, and the client had nothing more than an ISP dial-up at less than 56 kbs.
>
>Most of the VFP->SQL Server setups I've seen have still involved LANs or Citrix, so I basically have two questions:
>
>1) From a syntax standpoint, what would you need in addition to the standard SQLCONNECT/SQLEXEC commands to an ODBC source? (As far as connection strings, etc.)
>
>2) Does this type of setup (someone accessing SQL Server tables from a VFP front-end with a dial-up connection of 56 kbs or less) even make sense?
>
>Kevin