System.Data.ODBC provider?

Jul 12, 2013 at 7:17 PM
Using FluentData, I've been trying to access an MS-Access db via a pre-configured ODBC connection (so, not OLEDB). Getting no where, I dug around in the source code and found that the .NET provider names are hard-coded based on the specified FluentData provider. So, in my case, when I specified the FluentData "AccessProvider", the underlying .NET provider name is automatically set to "System.Data.OleDB".

I've replicated the "AccessProvider" class as "AccessProviderODBC" and (only) changed the associated .NET provider name to "System.Data.ODBC". This seems to work as expected and I can now access data via the ODBC provider.

So, two questions:
  1. Do you see anything wrong (potentially dangerous) with what I've done?
  2. I'm curious why the .NET provider names are hard-coded based on the specified FluentData provider? Since that info (the .NET provider name) is already specified in the connection string, why is the specified driver not just used directly?
Anyway, FluentData looks like a really nice piece of work and I appreciate that you've made it available to the community. So, a BIG thanks from me!

Any input on the above is appreciated.

Jeff Godfrey
Sep 20, 2013 at 11:03 PM
After more than 2 months of no response, consider this a friendly bump. ;^)

Any input on the above 2 questions would be appreciated.

Jeff
Sep 21, 2013 at 7:02 AM
Thanks for reminding me about this topic.

I haven't look into ODBC for quite some time, however as long as the ODBC component is implementing the DBProvider factory in .NET (and since you are able to execute a query then it does this) then there is no problem doing it in this way.

I agree with you that it should be possible to define the provider name.

There are two places where it can be done
1) When calling ConnectionStringName then FluentData can check if there is a provider name defined, if so use that.
2) Have a constructor parameter in each provider class that takes a provider name but with a default value defined. So both of these would be valid ways:
new DbContext().ConnectionString(GetConnectionString("Access"), new AccessProvider()); would use System.Data.OleDb
and
new DbContext().ConnectionString(GetConnectionString("Access"), new AccessProvider("System.Data.ODBC"));

I will fix the first one for you now and take the 2nd one as part of a bigger update later. I will notify you when it's done.


Lars-Erik
Sep 21, 2013 at 6:20 PM
I have now checked in the changes:
1) DbContext.ConnectionString method has been changed to take one more optional parameter, the providerName. If it's not set then the one from the fluent data provider will be used.
2) DbContext.ConnectionStringName has been changed to use the connectionString providerName from the .config file if it's set, otherwise it uses the one from the fluent data provider.

Can you please just get the latest source code and see if it's working as expected?
Sep 23, 2013 at 1:37 AM
Thanks for the replies and the enhancements. Unfortunately, I'll be traveling for the first part of the upcoming week and will be away from my development environment. I'll be sure to check out the update as soon as I'm back though.

Thanks again.

Jeff
Sep 26, 2013 at 9:14 PM
Not much time for testing today, but I was able to verify that the ConnectionStringName update is working as described for me. I'll try to check out the ConnectionString modification soon and report back here.

Thanks again.

Jeff
Sep 27, 2013 at 5:22 PM
I've done some limited testing with the new ConnectionString() changes and everything seems to be working properly. Thanks for your efforts!

Jeff