Re: issue 94543, some progress and request for help

On Fri, 2010-04-09 at 16:37 -0400, Terrence Enger wrote:
> Digging around on the web, I found "Technical Standard, Data
> Management: SQL Call Level Interafce (CLI)"
> <http://www.opengroup.org/pubs/catalog/c451.htm>.

Greetings,

I have pressed on with the notion of retrieving the character
representation of timestamps, and have some results good enough to
keep me interested: a timestamp retrieved via odbc from an AS/400 is
accurate to the centisecond (although the only way I know to see the
result in this precision is to format the result as a floating point
number).

The interesting part of the code, within
connectivity::odbc::OResultSet::getTimestamp
(connectivity/source/drivers/odbcbase/OResultSet.cxx), is

    m_bFetchData            = false;
    ::rtl::OUString aString = getString();

This suggests lots of questions.

(*) connectivity::toDateTimeString
    (connectivity/source/commontools/CommonTools.cxx) omits the
    centiseconds from a DateTime.  I presume that this behaviour must
    be maintained, right?

(*) m_bFetchData is defined in
    connectivity/source/inc/odbc/OResultSet.cxx with the comment "true
    when SQLGetData can be called in any order or when fetching data
    for m_aRow".  If I understand what gdb shows me, with the new
    assignment to m_bFetchData, the first recursion level of
    connectivity::odbc::OResultSet::getTimestamp eventually calls
    SQLGetData instead of connectivity::toDateTimeString.  This leaves
    me uncomfortable with the assignment to m_bFetchData.

    (a) Assigning m_bFetchData = false seems to contradict both the
        first alternative given in the comment and the meaning of the
        variable name itself.  Under what conditions would it be wrong
        to call SQLGetData?  Does OO sometimes bind a result column
        to a variable, and does this then prevent SQLGetData?  I can
        research this one myself, but maybe someone here just knows.

    (b) In ann earlier hack of mine, which delivered the same results,
        the the first recursion level of
        connectivitiy::odbc::OResultSet::getTimestamp deferenced
        m_aRow[columnIndex] to get the DateTime built by the second
        recursion level.  So the assignment to m_bFetchData is in the
        ballpark of the second alternative in the comment.

    Anyway, at the end of
    connectivity::odbc::OResultSet::getTimestamp, state differs from
    the state as left by the almost-original code in that (at least)
      - m_bFetchData is false instead of true.
      - retVal.HundredthSeconds is right instead of a pseudo-random
number.
      - m_bNull is true instead of false.
      - m_aValue is NULL instead of a pionter to a DateTime.
    I have not happened to notice bad results, but that is worth
    little.

    All this leaves me feeling a need for correction or reassurance,
    as the case may be.

(*) Speaking of recursion ... The assignment to m_bFetchData avoids
    the recursive call to connectivity::odbc:OResultSet::getTimestamp
    (and thence to other routines).  I would guess that this is good,
    except that it seems too easy.


Possible next steps include the following.  I welcome your guidance.

(*) To look for a situation which will expose a fault in
    similar-looking code in ODatabaseMetaDataResultSet::getTimestamp.

(*) To try the same test cases against other databases that I can get
    my hands on.  MySql and Postgresql come to mind.  danros66 already
    reported that DB2/UDB works like DB2/400.

(*) Search for a condition to expose bad results from similar-looking
    code in ODatabaseMetaDataResultSet::getTimestamp.


Thank you all for your patience with a newbie.


Cheers,
Terry.