>>I am wanting to move my company's main application from DBF tables to SQL Server, but keep the app in VFP (for now).
>>
>>I have tons of VFP code in about 20 forms that relies on opening DBF free tables and setting relations between the various tables in the LOAD event of the form (actually it calls a custom function in the LOAD event to do the work). I want to move the data to SQL Server so I can begin to develop .NET programs against the same data tables over the next year or so as I move all the app over to .NET. During that time, we would have .NET apps and VFP apps working on the same data in SQL Server.
>>
>>I have a couple of forms that seem like they will be particularly challenging, since they use a VCR control to do do "SKIP 1" or "SKIP -1" on the master table and that automatically moves all the pointers in the related tables.
>>
>>So how does one begin this move?
>>
>>I have SQL Server express running, and I have "pushed" a test copy of the data over to it, using the Upsizing Wizard. I first had to put the tables in a DBC, but then I was able to get them pushed over.
>>
>>Now the challenge is know the right way to re-write my app code to work off of the SQL Server.
>>
>>Do I need to plan on using a DBC and creating remove views to each table the SQL Server?
>
>A fairly straightforward approach is to use SQL pass-through to retrieve records from the server into VFP cursors. They can even be given the same names as your old DBF aliases to minimize code changes. You can then perform record based operations like SKIP on the cursors. If your forms are doing updates, you will have to recode those routines to send UPDATE commands to the server. It's not too bad.
>
>If you use SPT rather than remote views, you won't need the DBC after you have upsized.

Why not use CursorAdapter? I think it would be even less changes and using CursorAdapter it is supposed to be easy to switch back-ends.