Thank you, Victor. I think this is a good way to go. I remember I think Michael Cummings, or perhaps someone else at our user group in Orange County recommending that same way.

>>I may start a new project that should at some point use SQL Server. I am wondering if it'd be best to use Local Views to handle tables and then switch the Remote Views to more easily move over to SQL Server, when it is necessary. Any advice is welcome.
>>
>>I would say go for an nTier setup and create business objects that load from a dataobject. that way you can change the back end to anything and only need to change the data layer. you can make you own or use something like MereMortals.
>>
>>Gary.

>The way I've done this is to actually start with remote views. Here is how I've done it.

>1. Create all your VFP tables so that they are compatible with SQL server (for example, no vfp "date" fields since SQL doesn't have that data-type - use date-time fields.
>2. Create a new database that has nothing but remote views in it. Use ODBC and remote views to connect to the VFP database. Sure - it seems odd to use remote views to connect to VFP backend, but it works just fine.
>3. Upsize all your VFP tables to SQL server. If you did set 1 right - then even the VFP upsize wizard will work perfectly!
>4. Now all you have to do is change the connection string that your remote views are using - point it to the SQL server instead of the VFP database - and yer done!

>I've done this a bunch of times and it's really worked out great for me.