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. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org