none
Any generic OLEDB wrapper available for ADO.NET connection? RRS feed

  • Question

  • Hi,

    Our application acts as an ADO.NET provider so that other applications can extract our internal data using standard ADO.NET interfaces (connection, command, etc.).


    Some of our customers are using a third party reporting product. This non-.NET product can access external data only via OLEDB. We have been asked to develop an OLEDB interface for our application so that this reporting product can use our application.

    Before we embark on this development work, I am wondering if there is any solution that is already available that can simply act as an OLEDB bridge for ADO.NET connectivity. This would obviate additional development work for us.

    Thank you in advance for your help.

    Regards,

    Peter



    Thursday, May 14, 2009 8:03 AM

Answers

  • I'm not aware of any such bridge. Typically the bridge operates in the reverse direction, from the older technology to the newer technology, as in the ODBC and OLEDB provider libraries for .NET.

    Now, you could consume a .NET provider through COM (OLEDB technology) and provide the programmable interface but the third party reporting product (I don't know what it is) may be limited to using either ODBC or OLEDB directly, in which case you will probaby need to create your own provider for one or both of these technologies. You will notice that pretty much every third-party database provider has separate products for each technology. 

    Another option would be to supply your data in another database format, which already has an OLEDB provider or ODBC driver. 
    Paul ~~~~ Microsoft MVP (Visual Basic)
    Thursday, May 14, 2009 12:29 PM

All replies

  • I'm not aware of any such bridge. Typically the bridge operates in the reverse direction, from the older technology to the newer technology, as in the ODBC and OLEDB provider libraries for .NET.

    Now, you could consume a .NET provider through COM (OLEDB technology) and provide the programmable interface but the third party reporting product (I don't know what it is) may be limited to using either ODBC or OLEDB directly, in which case you will probaby need to create your own provider for one or both of these technologies. You will notice that pretty much every third-party database provider has separate products for each technology. 

    Another option would be to supply your data in another database format, which already has an OLEDB provider or ODBC driver. 
    Paul ~~~~ Microsoft MVP (Visual Basic)
    Thursday, May 14, 2009 12:29 PM
  • Paul,

    Thank you for your help.

    I ended up writing an OLEDB provider.

    Regards,
    Peter
    Thursday, May 28, 2009 6:43 AM