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.


>I got pointed to this link http://www.easysql4fox.vallmind.com/EasySQL4Fox.html which seems to offer some help in converting VFP to SQL backend.
>
>>First of all, thanks to everybody for their responses.
>>
>>I had not been considering SQL Server (or SQL Server Express) mainly because, well, I did not know enough to consider it.. As it happens, to nobody's surprise, we are running SQL Server, but at this time I have read-only access.
>>
>>I have noted with interest the discussion and SQL Server Express, and am not at all concerned, for one thing, about the database size. This project is quite small, even by the standards here at Kong, where the entire VFP universe, all in free tables, probably does not at up to 2 Gig. I wouldn't be surprised if this project never gives to 50 Meg total.
>>
>>So, I could install SQL Server Express locally, create the project, and then eventually (after I've gotten full access) make it available to my client (uh, my employer) for them in SQL Server.
>>
>>Assuming I'm not interested in scalability or portability, why would I want to go this route?
>>
>>>>Can somebody supply some recommendations, with both advantages and disadvantages, about using DBCs?
>>>>
>>>>I have never used a DBC, but am starting a new project of some size and would like to at least consider whether this is the time to start dong so.
>>>>
>>>>Thanks in advance
>>>
>>>Is there some reason you are not considering SQL Server instead? There's a free version which will handle moderate sized apps. And if your target is corporate, you won't be laughed out of the room for suggesting a toy database like you will with FoxPro.