Fog Creek Software
Discussion Board

Creating an ODBC driver for .NET application

I've got a product that is driven by meta-data. Consequently it has an interesting data schema to store the information. The product provides functionality to run queries but these are not standard SQL.

One of our potential clients wants to be able to run standard reporting tools against our data.

One of the options (short term) is to schedule a job to run to replicate and transform the data into a read-only database with a SQL-queryable schema so that 3rd party reporting such as Crystal can be run against it.

Longer term I'm thinking about creating a standard ODBC interface to the data, which would in the background go through the business logic to effectively perform the SQL queries.

Has anyone implemented an ODBC driver? The product is .NET. I'm not usre what one would have to do to implement an ODBC driver to a .NET backend, how much effort it would be etc. Buying in the skills is an option. Anyone got any ideas?

Thursday, August 5, 2004

Maybe look at stuff like ?

Just me (Sir to you)
Thursday, August 5, 2004

.Net already has an ODBC data provider. From the .Net standpoint, as long as you've written an ODBC driver (which itself does not get written in .Net), then you're set to use the ODBC data provider.

However, if you don't want to write an ODBC driver for you data, then you may just want to write you're own data provider in .Net.

Thursday, August 5, 2004

Perhaps it would be better to write an ADO.NET Provider for the data, then you wouldn't have to bother with all the ODBC-interop stuff.

This would be a nice solution, as you'd stay within .NET, but would only be suitable if the reporting software you wanted to use would work against ADO.NET, which should be most of them these days.

Thursday, August 5, 2004

Exposing .NET data via ODBC will be a major pain, if not impossible. The reason is that ODBC drivers are traditional DLL's; .NET makes it easy to call regular DLL's from managed code, but as far as I know you can't write regular DLL's in managed code and have it called like a non-managed DLL.

However, you *CAN* create COM objects in .NET, which leads to a different data access solution: OLEDB. This is all COM based, and "standard reporting tools" (cough Crystal Reports cough cough) should be able to handle an OLEDB provider just as well as an ODBC one.

Building neither type of software (ODBC driver or OLEDB provider) is easy. You WILL need to drop down into C++ at some point. And both are hellishly complicated. Don't expect this to be easy; it wouldn't be even if .NET wasn't involved.

Chris Tavares
Thursday, August 5, 2004

*  Recent Topics

*  Fog Creek Home