Matt,

If your app is multi-user, I wouldn't use DBC's and remote views. There are some resource contention issues with that approach.

My preferred approach is a "data layer" between your app and SQL that returns the results/data in either collections or CursorAdapter objects -- but that may be too involved for what you're wanting to do. I've actually built a few of these -- please message me privately if you're interested in more details (don't want to bore everyone here with my prattling about them :) )

Evan

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