On Mon, 2011-08-08 at 16:14 +0100, Caolán McNamara wrote:
> On Sun, 2011-08-07 at 11:32 -0400, Terrence Enger wrote:
> > (snip)
> > This table is described in bug
> > 34309 "error on importing a timestamp field from db2 via
> > ODBC" <https://bugs.freedesktop.org/show_bug.cgi?id=34309>.
>
> *assuming* I'm looking at the right code for the those timestamps. The
> conversion from LibO's fraction of a second to the sql one looks ok,
but
> the conversion from the SQL one to the LibO one looks odd on the face
of
> it. I suppose we won't get lucky here and the patch I attached to that
> bug makes any difference to the core issue of "Strange conversion on a
> time-stamp field" ?
But unless the inbound conversion has always been wrong for
everybody, there is some database system somewhere that
needs the multiplier to be 1000. I can *imagine* doing
something like
select timestamp('2011-08-08.010000')
- timestamp('2011-08-08.000000')
from SYSDUMMY1
but LO diagnoses a SQL syntax error, so I have hit an SQL
manual. Beside that, I do not know that every database
system provides SYSDUMMY1.
On the other hand, the document "Technical Standard: Data
Management: SQL Call Level Interface (CLI)", (C451) from The
Open Group says on page 60, that's page 78 within the .pdf
file, under the heading "4.8.3 Permitted Combinations",
DATE, TIME and TIMESTAMP have no standard host-language
support in either C or COBOL, and values for such
columns must therefore be both supplied and retrieved as
character strings (see Transfers with Conversion to/from
String on page 62).
Back in the days of OpenOffice, I had a local hack to
OResultSet::getTimestamp(sal_Int32) in file OResultSet.cxx
which made code convert the timestamp to a character string
and then to a DateTime. So far as saw, this seemed to
deliver the right right results, but I only saw a little bit
of data and only from a connection to DB2/400.
I have been holding off commenting on bug 34309 in the hope
that I can first verify my memories against a running
current version of LibreOffice. I even had hopes of
offering a patch, albeit more to show willing than in the
hope that it would be deliver a final solution to the
problem.
>
> > (*) Up to this point, the assertion "operator delete
> > mismatch" at operators_new_delete.cxx at Line 96 has
> > been raised five times. (I have reason to believe that
> > the problem is in the IBM-supplied ODBC driver.
> > Openoffice.org declared the bug WONTFIX, and I concur.)
>
> I wonder. You can put a breakpoint at
> sal/cpprt/operators_new_delete.cxx:96 and get some backtraces from the
> deletes to see where they are coming from.
I have done that, and I saw the IBM library doing the call.
But I have not done it very recently, hence my mealy-mouthed
"have reason to believe".
> Which bugid got closed as
> WONTFIX btw ?
The bug is number 110236 "Error: operator delete mismatch"
<http://openoffice.org/bugzilla/show_bug.cgi?id=110236>.
Whoops! I shudda said INVALID. And I still concur, given
that INVALID means, "It weren't me wot did it, guv'nor".
BTW, I am "400guy" in the oo.o bug system.
>
>
> > Questions arising ...
> >
> > (*) Are raised assertions (except this particular operator
> > delete mismatch, of course) grounds for submitting a bug
> > report? Always so? I presume a backtrace would be
> > useful. What else?
>
> What's worthwhile if you can practically achieve it is to install
> valgrind, export VALGRIND=memcheck and then try your tests. i.e. rule
in
> or out a generic bug which valgrind can find.
My system has 512MB of storage; I have been assuming that
this rules out use of valgrind. Right? (I have been in
resolute denial about memory issues since the OpenOffice.org
web site said that you should have 1GB if you want to start
hacking. "I'm innocent, guv'nor. That's my story, and I 'm
sticking to it!")
I still wonder, how much attention does the project want to
pay to raised assertions in general?
Thanks,
Terry.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
