none
Upgrade SQL DB Library API with latest API RRS feed

  • Question

  • We are using an C/C++ application where we use SQL DB Lib API to communicate with SQL Server. We need to upgrade the library since DB Library is deprecated. Need inputs to replace the DBLib API with latest compatible API with minimal changes to the existing functionality. Need inputs on it. Request anyone to provide their inputs at the earliest?
    Thursday, February 26, 2015 11:31 AM

Answers

  • FreeTDS is a third-party product, and to my knowing it is not endorsed or supported by Microsoft.

    And to clarify this a little further: Microsoft does of course only support their own products. If you use a third-party API, you will have to ask to support from the vendor. Since FreeTDS is free and open source, there is no vendor, but possibly someone is offering support for a fee. Beware that in either case, if there is an issue, you may run into finger-pointing. That is, the vendor may blame Microsoft and vice versa.

    I don't know about the situation and the expected life-span for your application, but I only see two alternatives:

    1) Stay where you are (and wait until Microsoft announced that they will no longer support connections from DB-Library.)

    2) ODBC. And, yes, this is a large investment.

    I would recommend that you first get your feet wet with ODBC but working with the samples that I referred you to. Once you have done this, you can better judge exactly how big will be for you.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Monday, March 2, 2015 11:43 AM
  • Of the three you listed, only one is still vital.

    OLE DB as such is still alive. But Microsoft has deprecated OLE DB for connections to SQL Server, so this is a dead end.

    ADO has not been touched this millenium, like DB-Library it does not have full support for all data types in SQL Server. So this is another dead end.

    Left is only ODBC which Microsoft keeps to enhance to support to new features in SQL Server. Of these three, ODBC is also the API which is closest to DB-Library. You still have a lot of work ahead of you, but less work that if you had settled for OLE DB.

    You can find sample code for the various APIs on this page:
    https://msftdpprodsamples.codeplex.com/

    I can definitely recommend these samples. Some ten years ago I embarked on a journey to implement a Perl API, and I used the OLE DB samples to learn the basics of OLE DB. (Yes, I chose to use OLE DB at the time. But given the development, this has proven to be a mistake.)


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Friday, February 27, 2015 1:15 PM

All replies

  • You should use the ODBC driver, SQL Server Native Client. All files you need come with the SQL Server install, but it is an optional component.

    ODBC is not overly similar to DB-Lib, so you have quite some work ahead of you. However, if you are using the bulk copy API in DB-lib there are some good news at least - the BCP interface in ODBC is a ripoff of the DB-lib interface.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Thursday, February 26, 2015 10:49 PM
  • Hi Erland,
    Thanks for your response!!
    I am a bit new to SQL API's. As I understand, we do have OLD EB, ODBC, ADO API's to communicate to any SQL Server databases.
    Our application mostly uses API's to connect, read the database and write to the database and GetResults via the DB-Lib API's
    Whether the ODBC driver or SQL Server Native Client will have equivalent API's so that there are minimal changes to the existing logic.

    Our application is a COM bases OPC Server which will talk to SQL Server databases. I am looking for some API which is as fast as DB-Library API and have minimal changes to have less impact on the existing functionality.

    Your inputs are on it are appreciated. Thanks again!!!

    Friday, February 27, 2015 9:24 AM
  • Of the three you listed, only one is still vital.

    OLE DB as such is still alive. But Microsoft has deprecated OLE DB for connections to SQL Server, so this is a dead end.

    ADO has not been touched this millenium, like DB-Library it does not have full support for all data types in SQL Server. So this is another dead end.

    Left is only ODBC which Microsoft keeps to enhance to support to new features in SQL Server. Of these three, ODBC is also the API which is closest to DB-Library. You still have a lot of work ahead of you, but less work that if you had settled for OLE DB.

    You can find sample code for the various APIs on this page:
    https://msftdpprodsamples.codeplex.com/

    I can definitely recommend these samples. Some ten years ago I embarked on a journey to implement a Perl API, and I used the OLE DB samples to learn the basics of OLE DB. (Yes, I chose to use OLE DB at the time. But given the development, this has proven to be a mistake.)


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Friday, February 27, 2015 1:15 PM
  • Thanks again for your response!!

    I have few other clarifications on it.
    1. Apart from ODBC, is there any similar API supported from Microsoft which can be used which is as fast as DB_Lbirary API?

    2. Any document or reference to convert DB-Library API to ODBC dirver or new API (if exists) which can be used for the development work?

    3. Does the new API/ODBC API can directly be used in our application with out any issues. I mean, distribution part/licensing, etc?

    One more point, as per the below article, ADO is going to be enhanced continuously. I guess, ADO is a Wrapper on top of OLE DB/ODBC and has less performance compared to ODBC/OLEDB?
    Please add http:// and type msdn.microsoft.com/en-us/library/ms810810.aspx in browser as I was not able to post link here.

    Do you have any information related to FreeTDS? freetds.org/userguide/what.htm

    FreeTDS has mentioned about replacement of DB-Library with CT-Library? Is this also being supported from Microsoft?



    Monday, March 2, 2015 5:02 AM
  • 1. Apart from ODBC, is there any similar API supported from Microsoft which can be used which is as fast as DB_Lbirary API?

    No.

    2. Any document or reference to convert DB-Library API to ODBC dirver or new API (if exists) which can be used for the development work?

    There might be, but I have never looked for any. Google may help you.

    3. Does the new API/ODBC API can directly be used in our application with out any issues. I mean, distribution part/licensing, etc?

    SQL Server Native Client is freely distributable.

    One more point, as per the below article, ADO is going to be enhanced continuously. I guess, ADO is a Wrapper on top of OLE DB/ODBC and has less performance compared to ODBC/OLEDB?

    No, that topic does not discusses ADO. It discusses ADO .NET and all that ADO and ADO .NET have in common are three letters. ADO .NET has nothing to with neither ODBC and OLE DB, but speaks TDS directly with SQL Server. It is a very good client API, but to embrace it, you would have rewrite your application to managed code, which is an even broader step than moving to ODBC.

    FreeTDS has mentioned about replacement of DB-Library with CT-Library? Is this also being supported from Microsoft?

    FreeTDS is a third-party product, and to my knowing it is not endorsed or supported by Microsoft.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Monday, March 2, 2015 8:27 AM
  • FreeTDS is a third-party product, and to my knowing it is not endorsed or supported by Microsoft.

    And to clarify this a little further: Microsoft does of course only support their own products. If you use a third-party API, you will have to ask to support from the vendor. Since FreeTDS is free and open source, there is no vendor, but possibly someone is offering support for a fee. Beware that in either case, if there is an issue, you may run into finger-pointing. That is, the vendor may blame Microsoft and vice versa.

    I don't know about the situation and the expected life-span for your application, but I only see two alternatives:

    1) Stay where you are (and wait until Microsoft announced that they will no longer support connections from DB-Library.)

    2) ODBC. And, yes, this is a large investment.

    I would recommend that you first get your feet wet with ODBC but working with the samples that I referred you to. Once you have done this, you can better judge exactly how big will be for you.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Monday, March 2, 2015 11:43 AM
  • Thanks a lot for your valuable inputs!!
    Tuesday, March 3, 2015 4:44 AM
  • Thanks a lot for your response!!

    The samples you have provided are only for SQL Server 2008. When I tried using with SQL Server 2012, most of them are not working since the data types being used not compatible in few cases.

    Tuesday, March 3, 2015 12:36 PM
  • The samples you have provided are only for SQL Server 2008. When I tried using with SQL Server 2012, most of them are not working since the data types being used not compatible in few cases.

    I have not tried the ODBC samples myself, but I fail to see why they would not be working with SQL 2012. Well, you have have to change the name of the include file to sqlncli11.h.

    Can you give some examples of what error you are getting?

    (Sorry for the late reply, but I was offline for the most of the past week.)


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Tuesday, March 10, 2015 10:57 PM