0

Can anyone help me understand what is the exact difference between a native database connector and ODBC connector. I googled a lot and found that , in native connector SQL, data and the actual interfaces built inside the application have been specially designed for a specific database.Now what is meant by "specially designed for a specific database" Lets say my code is written in C++ and I use a native connector to connect to SQLServer. How will it differ using a native connector wrt using a odbc connector. Pardon me if this is a stupid question.

http://www.information-management.com/news/ask_the_experts/-1077488-1.html Thanks, Neethu

Neethu Lalitha
  • 3,031
  • 4
  • 35
  • 60
  • See this answer here: http://stackoverflow.com/questions/103167/what-is-the-difference-between-ole-db-and-odbc-data-sources The native connector SQL would be the arrow on the leftmost side, it interacts directly with the database, without any layer of abstraction in between. – erg Sep 21 '16 at 07:27

1 Answers1

1

ODBC is a generic, DBMS-agnostic API.

ODBC Drivers mediate between this generic API and the DBMS-specific APIs of DBMS clients and/or engines.

If you write your code to the ODBC API, and use only generic query syntax (no DBMS-specific query syntax, like Transact-SQL for Microsoft SQL Server, or Oracle-SQL for Oracle), it may be run against any ODBC driver and thus any DBMS, typically with minimal additional testing or code work.

If you write your code to a DBMS-specific API, or use DBMS-specific query syntax (such as Transact-SQL or Oracle-SQL), it can only be run against that DBMS, and only through those DBMS client libraries -- which may even be DBMS version specific. Adapting to a different DBMS or to different versions of the same DBMS and/or its client libraries can require significant testing and code work.

This compiled-app (no need to recompile, relink, etc.) portability and future-proofing (within some limits) is the basic value proposition of both ODBC and JDBC, among other DBMS-agnostic data access protocols.

TallTed
  • 9,069
  • 2
  • 22
  • 37
  • Odbc also offers a more fixed set of options. If you want to offer special augmented features you don't control ODBC. You can add these additional features to the API. But if ODBC does not have code for it you won't get support for your additional features. Using one vs the other can influence your applications speed. – M T Head Sep 20 '16 at 17:06
  • [Performance analysis of ODBC vs "native" API is old news](http://www.drdobbs.com/performance-testing-odbc-and-native-sql/184410033). Some client-layer features may require changes in the ODBC protocol (today at 3.5.8; still evolving), but most augmentation takes place in the DBMS engine, which an application can interrogate _(what DBMS are you? what version?)_ and then address specifically _(if I know the engine, use this optimized command; else, use this generic)._ For most applications, assuming a well-written driver and a well-written application, ODBC delivers more than sufficient speed. – TallTed Sep 20 '16 at 18:10