Re: issue 94543, some progress and request for help

Moin Terrence,

Terrence Enger wrote:
> 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?
>   
To be deleted would be better and to use the version from 
DBTypeConversion :-)
Could you please submit an issue for this. Thanks.
> (*) 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.
>   
No. Do you see the not before it? :-) It is true when it can not be 
called in any order.
>     (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.
>   
We still have a problem with the com:.sun;:star::util::DateTime which 
lacks of the capability to hold more than just HundredthSeconds. So 
times less than that can not be queried or updated today.


Best regards,

Ocke
>
> Cheers,
> Terry.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>   


-- 
Ocke Janssen                      Tel: +49 40 23646 661, x66661
Dipl. Inf(FH)                     Fax: +49 40 23646 550
Sun Microsystems Inc.
Nagelsweg 55                      mailto:[email protected]
D-20097 Hamburg                   http://www.sun.com/staroffice

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Juergen Kunz