Kevin,

First, no, I haven't done anything with multiple back-ends, only SQL Server.

Second, yes, accessing SQL Server with the OLEDB objects rather than the SQL objects *is* slower.

Third, the SQL objects are sub-classed from the OLDDB objects, so perhaps you can still have generic classes and pass whichever type you're using as an object parameter or something. I haven't totally thought it through, but I bet it's do-able without too much headache.

~~Bonnie


>Hi, folks...
>
>Two questions...
>
>First, we recently learned that our app *may* need to support either SQL Server or Oracle. Up to this point, we've been using SQLCONNECTION, SQLADAPTER, and SQLCOMMAND in our data access component. Obviously (or at least I believe obviously), we could be more generic and use OLEDBCONNECTION, OLEDBADAPTER, and OLEDBCOMMAND instead. However, I've heard (2nd hand) that those commands are slower than the SQL command counterparts. Is this true?
>
>If it is, then I have a 2nd question...we considered have a general CONNECTION method (and a general ADAPTER method and a general DBCOMMAND function), where we'd issue either a SQL... command or an OLEDB...command. However, it also occured to me that since these 'generic' functions need to return something (a connection handle, a reference to an adapter) that would be stronly typed, we'd need to go a step further...and that seems more complicated than necessary.
>
>So has anyone tried to write generic methods to deal with this type of access (SQL vs non-SQL Server), and what approaches have they tried? (And if anyone has any URLs that cover this type of thing, that would also help)
>
>Thanks,
>Kevin