SQL Server Performance

What is the best approach to develop applications with SQL Server 2005?

Discussion in 'SQL Server 2005 General Developer Questions' started by dayakarr, Dec 26, 2008.

  1. dayakarr New Member


    I have an application which uses DB-Library API's to interact with SQL server 2000. I am supposed to upgrade this application to support SQL Server 2005.

    As DB-library will be deprecated very soon, I want to use latest native library. I learned about 'SQL Native Client'. BUT did not find api documentation like 'DB-library'.

    1) Do we have any article talking about - how to migrate DB-library application to use 'SQL Native Client'?

    2) I am not still clear about how to use native apis to connect with SQL Server 2005. Do I need to use ODBC apis or OLE DB?. These are generic approaches. Don't we have native apis like DB-Library ( dblogin_t ) in SQL server 2005.

    Awaiting for reply,

  2. satya Moderator

    Welcome to the forums.
    Such information about native client tools is available on MSDN and even in SQL SErver 2005 books online, for instnace: http://msdn.microsoft.com/en-us/data/aa937733.aspx
    http://sqlserver-qa.net/blogs/sql2008/archive/2008/06/16/4285.aspx - mdac vs native client.

    Using ADO with SQL Server Native Client

    Data Access blog : Introducing SQL Native Client

    SQL Protocols : Encrypting connections in SQL Server 2005 & SQL ...

    Download details: Feature Pack for SQL Server 2005 Apr 2006 where you will see the feature pack that is required for SQL 2005 version.

    FYI still the older client connections will still work with 2005 version, no specific requirements to get work the native client or ODBC or OLEDB.
    If you start discussion about which is better or good to use then it is never ending topic, you must deploy the required one as per the necessity:
    ODBC was and is one of the oldest technologies. It was developed by Microsoft and probably is one of the few Microsoft technologies to become popular without being questioned. It is widely "seen as an open" standard WITH limited in its functionality and provided low-level database access.

    ADO added more features and made accessing data much more easy by implementing a matured Object Model. ADO was a matured data access method which was built after using the experiences gained by DAO and RDO implementations.

    OLEDB WITH fully COM based (COM+ to be precise). DAO had become rather complex. Data access object models came once full circle when OLEDB came. It implemented a rather simple Object Model (which looked more like JDBC).

    ADO.Net is a later version of ADO which was developed keeping in mind .Net computing framework. ADO.Net is very different (and supposedly much more efficient).
  3. Kewin New Member

    I still have an ancient app that runs towards a SQL Server 2005 happily based on dblib.

    We're not going to touch it basically since it's not required to do anything more than dblib is able to provide.
    'If it works, don't fix it' is sometimes good enough.
  4. moh_hassan20 New Member

    review: http://technet.microsoft.com/en-us/library/aa936940(SQL.80).aspx
    excerpt ....While the DB-Library API is still supported in Microsoft SQL Server 2000, no future versions of SQL Server will include the files needed to do programming work on applications that use this API. Connections from existing applications written using DB-Library will still be supported in the next version of SQL Server, but this support will also be dropped in a future release. When writing new applications, avoid using DB-Library. When modifying existing applications, you are strongly encouraged to remove dependencies on DB-Library. Instead of DB-Library, you can use Microsoft ActiveX® Data Objects (ADO), OLE DB, or ODBC to access data in SQL Server.

Share This Page