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: dev-unsubscr...@dba.openoffice.org
For additional commands, e-mail: dev-h...@dba.openoffice.org
--
Ocke Janssen Tel: +49 40 23646 661, x66661
Dipl. Inf(FH) Fax: +49 40 23646 550
Sun Microsystems Inc.
Nagelsweg 55 mailto:ocke.jans...@sun.com
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org
For additional commands, e-mail: dev-h...@dba.openoffice.org
