You are going to have issues if you do not control the table structures of the database what ever it may be. I do not have this problem because I do have control. When I have a VFP DB, I design it with Oracle and SQL Server requirements in mind. e.g., I do not use logical data types. So when upsizing happens, my server tables are at least compatible with what they were in VFP. So all you are concerned with is the connection. If you keep your connection string in a commonly accessible table or file, all you have to do is change the string and you are done. Alternately, this could just be changing a DSN, or a constant in a header file and a recompile.

If you have table structure issues, there are ways to get this info from SQL Server and Oracle that you can make a part of your framework. Then you get into the issues of multiple table updating, identifying the PKs, etc. All of this is do-able, it's just easier to design your database with cross DB compatibility in mind.

I use my CABuilder to create my classlibs of CAs, and I do not have to change anything in them regardless of the DB because I do control the DB design. My DataSource for my base CA Class is a call to a function that returns the ODBC connection handle. So if the connection parameters change, I just modify a constant in my header file and recompile. Again this can be handled by a DSN, a string in a file or table, etc.

>Mark,
>
>Here's the big picture.
>
>I want to create a class that allows me to pull from either VFP,
>SQL or Oracle. This class would all me to determine the structure
>of the data returned, so that I can minimize changes to the BO's
>and GUI.
>
>I'd like to build both this class and the BO's as COM objects, so
>working with XML would be prefered. This would allow me to swap
>in a new data class when the back end database changes.
>
>I have Doug Hennig's articles on CursorAdapters, but the XML examples
>are geared towards web access.
>
>So, thats the idea. Any thoughts?