>What I've done in the past is design my tables so they're SQL Server compatible (i.e., use all datetime fields and no date fields, no time fields) - this way upsizing the data is a snap.
>
>Once your VFP tables are this way, use REMOTE VIEWS for everything. Yes it seems strange to use remote views to access native VFP tables - but there is good reason for this. In your case this is probably going to be the most complicated part since you're not using views of any kind yet. You're probably going to have to redesign a few things to work with parameterized views instead of tables.
>
>Now, once you've done all this - all you have to do is upsize your VFP tables to SQL Server tables. To get your application to use the SQL tables instead of the VFP tables, all you have to do is change the connection string that the views are using. So now you can switch between VFP tables and SQL tables - and you don't even have to recompile - all you have to do is make one small change in the .dbc that holds the remote views.
>
>IMO this is the best way to handle this situation.
>
>>I have developed a mature big application ( 200 installations in last 5 years) that is based on VPF native tables. Most of the business rules are on the form level. Most of the insert, update, and retrieve of data are based on SQL commands. I do not use views at all.
>>
>>Lately some of my customers require to transfer the date into SQL database, for good reasons: security, huge tables (millions of records), remote access etc.
>>
>>I have two options:
>>
>>a) Copy the existing project into a NEW project and modify the existing application to work only with SQL databases.
>>
>>b) Modify the existing application on the logic:
>>if lsqlmode
>> new code for sqldatabase
>>else
>> the oldcode
>>endif
>>
>>What option should I choose?
>>Is the second option realistic?

Remote views is not an option. What about CursorAdapters?