I didn't take the time to read all the responses - so hopefully I'm not just repeating what others have said...

The way I've handled this in the past:
1. Make sure all the VFP tables are compatible with SQL Server (no date fields, no time fields, just datetime fields...etc)
2. Create a new DBC. This will having nothing in it except for connections and views.
3. In the new DBC create an ODBC connection to the VFP database.
4. Change your application to use remote views to the VFP database. Needless to say this could take some time depending upon how the application was written. Remember you don't have to do it all at once - you can do it my screen or module or whatever....
5. Upsize your VFP tables to SQL server.
6. In the DBC with the views - change the connection string to hit SQL server instead of VFP - and pooof! yer done!

....Now I've done this quite a few times in the past now. You don't have to migrate the whole app at once - and you don't have to migrate all the tables at once either. I've been in situations where as this was gradually being done some of the tables were in VFP and others in SQL server - it all kind of depends on how you plan to attack it.... Heck you're kind of lucky that would be a fun project!


>We are planning to rewrite a VFP application which uses DBFs to .NET and SQL Server. The system is extremely large and is comprised of a large number of subsystems invoked from a main PRG and menu. It is not considered feasible to convert everything at once. Instead the plan is to rewrite a piece at a time as resources and budget become available. Has anyone done something like this? To me it seems like the data is going to have to reside in both VFP and SQL Server until everything is converted. Any tips on good ways to do that?
>
>Thanks in advance.