Kevin,

As Stephen said, there are still different code bases to maintain, no matter which way you handle it. IMHO, I believe it's easier to use Stored Procs, name them the same, have them return the data in exactly the same manner (same number of tables, same number of columns in the same order).

Then, your actual C# code will be using all the same logic (same DataSets, same Stored Procs), you'd only be changing how you connect (SQL or Oracle) and the Command and DataAdapter objects you use. I know Kevin Goff would mention something about ProviderFactory or something like that (sorry, I forget exactly what it's called because I'm not using it ... but I should be I suppose). The way I'm doing it, I'd have two "base" classes, one to handle SQL calls and one to handle Oracle calls and they'd all be using the various Interfaces (like IDbConnection I think it's all called ... this is all very much off the top of my head after a long and trying day, so cut me some slack if my syntax is off a bit <g>). Name them the same and then use whichever one is appropriate to your customer. Anyway, then all your DataAccess classes are sub-classed from this base class and all of the actual access is abstracted enough that your sub-classes don't know or care whether they are accessing SQL or Oracle.

I hope this makes sense. I've had a rough day ... I'm going home.

~~Bonnie




>I a building an VFP app that passes client-side queries through a .Net data access class to either MS SQL or Oracle, depending on which DB we're connected to.
>
>I would like to create a C# component that simple receives a call, such as GetClientName(), and then
>returns the data regarldless of the DB.
>
>Stored proc's are out as we don't want to maintain a different base of code in each DB.
>
>The problem then is that storing the queries in a C# class means formatting the queries and commands
>to the target DB.
>
>Can anyone point me in the right direction on this?
>
>Thanks