Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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.



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.