Database Access

This is a discussion on Database Access within the C++ Programming forums, part of the General Programming Boards category; Do you know if there's a DBMS independent library like JDBC? So far, I've seen SimpleDB and DTL, but they ...

  1. #1
    Registered User
    Join Date
    Dec 2006
    Posts
    8

    Database Access

    Do you know if there's a DBMS independent library like JDBC? So far, I've seen SimpleDB and DTL, but they don't seem to be well supported.

  2. #2
    Registered User
    Join Date
    Dec 2006
    Posts
    8
    I've found the following:

    SOCI - The C++ Database Access Library http://soci.sourceforge.net/index.html
    SimpleDB http://simpledb.sourceforge.net/
    Oracle, Odbc and DB2-CLI Template Library http://otl.sourceforge.net/
    Database Template Library http://dtemplatelib.sourceforge.net/index.htm
    hk_classes http://hk-classes.sourceforge.net/ti...me=Description

    SOCI seems to be cool, as well as DTL.

  3. #3
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    Ideally you would want some library that doesn't connect through ODBC. SQLAPI++ appears to be a good solution if it wasn't for the fact it costs around 250 USD.

    SOCI seems to be almost ideal, only for MS SQL Server will it connect through ODBC.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,431
    Ideally you would want some library that doesn't connect through ODBC.
    Why is this so?
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,473
    Quote Originally Posted by laserlight
    Why is this so?
    Have you read my mind?
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  6. #6
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    Purely for performance reasons. ODBC adds another layer that can be bypassed if the server engine offers a direct connection through an API of their own.

    An independent library that can take advantage of an existent API is always a bonus, I would say.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #7
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,473
    Quote Originally Posted by Mario F.
    Purely for performance reasons. ODBC adds another layer that can be bypassed if the server engine offers a direct connection through an API of their own.

    An independent library that can take advantage of an existent API is always a bonus, I would say.
    But he wanted the DBMS independent... And you're talking about DB server API. For me it's like using something DBMS dependent... Isn't it?
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  8. #8
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    An indepent driver for DB access will use whatever mechanism that shortens the distance between the driver API and the DB Server.

    Take a look at the JDBC. Particularly the second graphic that shows access to a Server that provides a client library with and without ODBC.

    What happens is that the server provides an API. An intelligent independent library will try to use the API directly, avoiding the extra ODBC layer, unless of course the coder establishes an ODBC connection (or the server administrator doesn't make the API available).

    For every server supported, the library driver can be designed to take advantage of the server API.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  9. #9
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    JDBC certainly isn't DBMS independant. The API is, but each DBMS has to ship their own JDBC driver implementation.

  10. #10
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Every DBMS has to ship their own ODBC driver implementation. The difference is?

    The important thing is that the choice is transparent to the user of the API. Which it is not quite, in JDBC (and AFAIK in ODBC), because there's always those pesky little SQL dialect issues.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  11. #11
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    >Every DBMS has to ship their own ODBC driver implementation. The difference is?

    No difference, just trying to clarify for the OP. They seem to think that JDBC is DBMS independant. ODBC is likely the tool they need.

  12. #12
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    He's looking for a library that can connect to several different servers. ODBC is not a library.

    freeodbc++ is, as any of the ones he shown on his post.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  13. #13
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    >Do you know if there's a DBMS independent library like JDBC?


    ODBC is the closest thing to JDBC for C/C++. Any specific library is going to be restricted to some set of DBMSs. If you write your program using the ODBC api, you can plug in whichever driver is supplied by the DBMS vendor.

  14. #14
    Registered User
    Join Date
    Dec 2006
    Posts
    8
    Wow! Thank you all for your responses, the discussion turned out to be very helpful.

    Just as a comment, after reading your posts i encountered with the following FAQ entry in the page of the DTL regarding ODBC, since this is the only method they use:

    Do you have any plans to add support for native drivers?

    Not any time soon. The primary reason for doing this would be performance. We have tried to encapsulate all of the ODBC calls in three classes called DBStmt, DBConnection and DBEnvironment so we could bind to a native driver should we so desire. In practice, this is not a priority for us since ODBC gives us good database portability and my belief is that, used properly, ODBC is just as fast (or faster!) than native drivers. The real key is knowing how to use the ODBC API effeciently by e.g. not re-connecting for each query, using bulk inserts to send large data sets, using forward only cursors to do simple reads and so on. As much as possible we have tried to use ODBC "best practices" in DTL so that we make efficient use of the API and code the uses DTL will be fast. We also provide a simple performance benchmark and "profile" project that we have used to track the overhead that DTL imposes above and beyond the ODBC API. Here are links to benchmarks that have been done to compare ODBC versus native drivers.

    Overview of ODBC perfomance v.s. native drivers and list of references
    ODBC v.s. native driver benchmarks
    More discussion of ODBC versus native drivers

    Thanks!
    Last edited by ivotron; 12-15-2006 at 02:10 PM.

  15. #15
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    Glad we could help

    However I can't but comment one passage of that quote:

    In practice, this is not a priority for us since ODBC gives us good database portability and my belief is that, used properly, ODBC is just as fast (or faster!) than native drivers.
    Assuming, 1. The Server ODBC implementation is not done through its API and 2. The server ODBC implementation is as fast (or faster!) than the server API.

    Also, while interesting to take a look at, the tests shown are 12 years old, one of the links points to a 404 and the other discussion topic is 13 years old.

    I'm not wanting to turn this into an against-ODBC diatribe, I certainly favor ODBC for its simplicity. But not only server APIs are much more refined these days with a strong demand for direct server access being a mainstream reality, but also ODBC is quiet often implemented in function of the server APIs creating an extra layer between the client application and the server.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Error connecting from Dev C++ to MS Access Database
    By Sridar in forum C++ Programming
    Replies: 0
    Last Post: 04-15-2006, 06:09 PM
  2. accessing a database made in Access..
    By willc0de4food in forum Windows Programming
    Replies: 4
    Last Post: 10-10-2005, 07:40 PM
  3. Access Database Editor
    By Grayson_Peddie in forum Tech Board
    Replies: 21
    Last Post: 01-06-2004, 06:20 AM
  4. DataBase access
    By itld in forum C++ Programming
    Replies: 2
    Last Post: 12-29-2001, 07:25 PM
  5. DataBase Access
    By itld in forum Linux Programming
    Replies: 0
    Last Post: 12-29-2001, 10:40 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21