Bob,
>Is this really practical with VFP as the front end and data stored on an SQL server?

This isn't really pratical but it is doable. Most likely you will have to rewrite your application to use data subsets. The average VFP local data application usually displays lists of data to pick from. Using an RDBMS over a WAN, this becomes too cumbersome. You need to ask for filter criteria so you can limit the amount of data that travels over the wire.

One way to alleviate some of this is to use SQL Server at all locations. That way you can use "local" data to help with network performance. You can then use SQL Server replication capabilities to centralize your data.

>
>Presumably this means that the EXE file will be stored on each location's PC.
>
>Will this result in a significant increase in accessing data provided of course the links between the SQL Server and each location are up to it?
>
>What should be the minimum data transmission speed between the SQL server and each location?
>

IMO, you will need fractional T1 (256K or better) or synchronous DSL (192K or better) to handle the throughput. Otherwise, your users will be complaining about the performance (and it won't be something you can fix).

>Obviously if I go ahead with this I am going to have to teach myself SQL Server and how to store data in it. Is this a pain or is it fairly easy for the average
>programmer?
>

The is a book available from Hentzenwerke on Client/Server development using VFP and SQL Server. Check out their site.

As for it being a pain or easy, it's in between. Like I posted above, you have to switch to a data subset paradigm. Once you've made this internal switch, things look a little easier. SQL Server SQL and VFP SQL are not 100% compatible and these differences may give you some headaches. But they aren't too bad (IMO) so you should be able to get through those times.

HTH.