>Interesting link - I had not seen that before. Anyway thought I'd jump in and put my 2 cents worth in......
>
>The way I've dealt with VFP -> SQL is simply to use remote views for everything. So basically here is the way I do it.
>
>1. Create a DBC with all your tables in it. When you do this - make sure the field types are SQL Server compatible. In other words - in VFP don't use Date fiields... don't use Time fields --- use DateTime fields because that's what SQL Server has.
>2. Create another DBC. In this DBC create a connection string to your VFP DBC.
>3. Now create remote views in DBC #2 and use these for your application.
>
>...So now you have 2 DBC's - one with tables, one with remote views. Your application uses nothing but the remote views.
>
>At this point - all you have to do is upsize your VFP tables to SQL Server. Assuming you did everything correctly (made sure all the data-types are compatible) even the sucky upsize wizard in VFP will work.
>
>Next - in your DBC with all the remote views - if you change that connection string to point to your SQL database instead of your VFP DBC - then your are done.
>
>I've done this a zillion times and posted about it out here before. It works really well - and by simply changing a connection string in the DBC you can switch between VFP, SQL, Oracle, MySQL or whatever back-ends and not have to recompile anything.
>
>The article seems neat & I'll take the time to read into it more - but I think my solution makes a LOT MORE sense.

Your way is basically the way CodeBook and Visual FoxExpress do it.