The POCO C++ Libraries Blog

The State of Data::ODBC

Filed under: Uncategorized by alex at 12:17

For those folks who have expressed interest in Data library, I’ve been spending some time these days with it and here is the current state of the affairs:

– I found a couple of bugs (logged in SF):


Drivers passing all tests:

Windows: MS Access, DB2, Oracle, MySQL, PostgreSQL, SQLServer, SQLite3

Linux (unixODBC): PostgreSQL, MySQL

If you are running on Linux, I strongly recommend to check out the recent SVN. Windows users should have no trouble with either 1.3 release archive or SVN code.

On Linux, FreeTDS connects to MS SQLServer but unfortunately bombs right on the barebone ODBC test, which likely means that the driver is either buggy or nonconformant (barebone ODBC test runs pure ODBC API calls without going through Data library). If anyone can find some time to track down what’s going wrong there, it will be appreciated. Given the amount of components involved (OS, ODBC driver manager, ODBC driver, database) it is practically impossible to test every combination, but we strive to have the most common cases covered.

In the meantime , I am working on stored procedure call support, configurable internal storage containers, DateTime binding etc for 1.3.1.

Until later,


  1. An update: the stored procedure support with tests is in SVN.
    Three new helper functions were introduced to work with stored procedure/function parameters/return values:

    in(), out(), io() – names are self-explanatory and they work in the same fashion as use() and into(). However, while use() is interchangeable with in(), into() is NOT interchangeable with out(). And io() is a story for itself – providing support for two-way parameters. So, it is best to think of use() and into() when dealing with parameterized queries, while in(), out() and io() are meant for stored procedures and functions.
    Here’s some code:

    session << "CREATE OR REPLACE "
    "FUNCTION storedFunction(param1 IN OUT NUMBER, "
    " temp NUMBER := param1; "
    " BEGIN param1 := param2; param2 := temp; "
    " RETURN(param1+param2); "
    " END storedFunction;" , now;

    int i = 1;
    int j = 2;
    int result = 0;
    session << "{? = call storedFunction(?,?)}", out(result), io(i), io(j), now;
    //after execution i == 2, j == 1, result == 3

    And, as an added value, tuples work, too:

    Tuple<int, int> params(1,2);
    result = 0;
    session << "{? = call storedFunction(?,?)}", out(result), io(params), now;

    Comment by alex on May 26, 2007, 01:24

  2. Some more updates:

    SQLServer stored procedures are giving me hard time. Anyone familiar with SQL Server willing to jump in and help?

    Now, to the brighter side. Internal storage is configurable now:

    session << "select * from table", vector, now;//default session << "select * from table", deque, now; session << "select * from table", list, now; The standard concerns related to particular containers apply. For example: if you choose list and later retrieve data using [] operator from RecordSet, you can do it (unlike with std::list), but things may get, well, slow. Know thy container prior to choosing one ;-). The best source is probably first two items in "Effective STL".

    Comment by alex on May 31, 2007, 12:28

  3. Another update:

    I’ve got the SQLServer stored procs figured out – it was my fault. Of course. It actually turned out to be a good thing that SQLServer driver is so picky because it has led me to discover a flawed approach I’ve had to the issue.

    Now the good news:

    DateTime binding is done – now a DateTime variable can be used in use() and into(). Oh, yes, same for in(), out() and io().

    Left on TODO list:

    – string and blob parameters out binding
    – Unicode (aargh!)
    – more stored procedure tests (PostgreSQL, DB2, any volunteers?)
    – polishing

    Comment by alex on June 6, 2007, 03:44

RSS RSS feed for comments on this post. TrackBack URI

Leave a comment