Thanks. Helpful. Especially the idea of a meta data table to define the tables.

>Yes, in theory you can access one table from the VFP database and another table from SQL Server database. But my customers use 100% VFP or 100% SQL Server.
>Basically my "framework" is based on a bunch of meta tables (.DBF tables) and a couple of BIZ objects. The meta tables define every table and every field in every table. And a few other things, index, and so on.
>Then, for each table in the application I create a BIZ object, based on the "main" BIZ object. I drop the table BIZ object on a form, set all controls of the form to the fields, and so on (I don't want to bore you with all the details).
>
>So, in theory, one table BIZ object could be pointing to the VFP and another to SQL. I just don't do it this way.
>
>>Hi Dmitry,
>>
>>That's helpful. Would you say that I using CA I could access VFP and SQL server data *at the same time* in a live environment or just one or the other? Your approach would make sense for a future cut-over date to SQL.
>>
>>
>>>Hi Albert,
>>>
>>>I have a very large vertical market application and the data access is built almost entirely on cursoradapter (I really like it). And I have some clients who use SQL Server and some who use VFP database. The same application; just some change of settings.
>>>If you were to go the cursoradapter (CA) route (and some may suggest other approaches), I would suggest to start changing the entire application to CA and VFP, module by module, or form by form. But, as you convert to CA, I would make the code work on SQL Server too (just as I do) with simply changing some settings. This way, you can test it - in-house - with SQL server while the customer is "testing" the existing VFP database. And at some point in time, when you see that the app can work equally well on SQL server, make a switch. I think in the process you will find that some parts of you application may need to be changed; but all in the interest of moving it to SQL Sever eventually.
>>>
>>>HTH