I'm jumping in here rather late, and I didn't read all the other posts, so I maybe be repeating stuff other have said. I've acutally done this with a least 10 VFP applications now.
The way I've done it:
1. Get all your table in a DBC, setup releationships and such there.
2. Make sure all your date and time fields are now datetime fields.
3. Use parameterizd remote views for everything. Obviously this is a rather big step, but a necessary one. Depending upon how the screens and such are setup, this can cause some screen redesign. Also - put all your remote views in a seperate, new DBC.
4. Upsize your DBC with all the tabls in it to SQL Server - I've done it with the wizard a bunch of times. The VCR buttons you have might have to go away depending upon how much data your querying, so like I said some screen desgin might come into play here.
5. Now all you have to do is change the connection string in your remote-views DBC to point to the SQL Server tables instead of your VFP DBC tables. I've even put a flag in some applications so you could go back and forth between the two. On some of the larger apps I've done, I've actually slowly migrated the data due to a large number of screens and such - so I would have like all the customer info in sql server tables,but maybe all the invoices in VFP tables - then as I make progress, upsize the tables as needed.

In your case, since it's all free tables and you're manually setting relationships in the load() event, you might just want to upsize the tables to SQL server to start with. Anyway, I really like remote views. A couple of the apps I've done this with were using all local parameterized views - needless to say those projects were easier to deal with.

I do think that in most cases this is a good way to go if you plan to convert the app to .NET. You can get the data somewhere that .NET apps can use it, and generally it takes a lot less time to switch VFP tables to SQL tables and tweak a VFP app to do than write a whole new .NET app.

>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?