https://bugs.freedesktop.org/show_bug.cgi?id=50575
Bug #: 50575
Summary: timestamps as primary column: show empty data /
crashes / ...
Classification: Unclassified
Product: LibreOffice
Version: LibO 3.5.1 release
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: major
Priority: medium
Component: Database
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected], [email protected],
[email protected]
Depends on: 47520
+++ This bug was initially created as a clone of Bug #47520 +++
<original text by Heinz Repp>
Using a version newer than 0.85 of the sqliteodbc driver results in some of my
tables showing only 4 empty rows, and this happened already with OpenOffice 3
and later with Libreoffice 3.3 and 3.4. Those tables have a timedate field as
primary key, and Christian Werner had changed the formatting of timedates
between 0.85 and 0.86 (millionth of seconds I believe) and told me, that in
this case the the handling of Base was in error, and I should avoid using
timedates as primary key, but that was no option. Now new with Libreoffice
3.5.1: when I try to open one of those tables with a timedate primary key
Libreoffice reproducibly crashes.
<Comments by Lionel Elie Mamane>
The problem is that Base handles timestamps only up to a precision of
hundredths of seconds. So when it tries to (re)load data in that row, it gets
no result and shows an empty row. The crash is "just" a lack of robustness in
the face of unexpected result (namely no data when data is expected). Also a
bug, albeit (again) a different one.
The real solution is to change Base to handle timestamps up to the full ODBC
precision of nanoseconds (billionths of a second).
This will still have problems when inserting a row with a Timestamp primary
key, and the data inserted has a higher precision (in the primary key column)
than what sqlite (or more generally the database engine) supports: Base won't
find the newly inserted row again when trying to (re)load it, leading to the
same problems described here for this new row.
More generally, this will happen for any primary key that contains data that
can get rounded/truncated by the database engine, and such primary keys will
"always" be fragile I guess (unless we find a better way to refer to a row than
by its primary key...).
Steps to reproduce:
See bug #47520
Notes for solving:
The limitation to hundredths of a second comes from :: com :: sun :: star ::
util :: struct DateTime, which (as far as I understand) is part of the UNO
"guaranteed stable" ABI. As such, we'd have to introduce a new
::com::sun::star::util::struct DateTime2 or some such with higher precision. Or
maybe a more "base-private" ::com::sun::star::sdb(c)::DateTime? Nah, probably
too confusing.
Then all places using ::com::sun::star::util::DateTime have to be changed...
The ODBC scaling factor (now ODBC_FRACTION_UNITS_PER_HSECOND) should ideally be
1, etc. That is not only in database-related stuff, so this will have to be a
concerted effort of all/several components.
Funnily enough, LibreOffice already has a (non-UNO exported) datatype for
timestamp with nanosecond precision, namely oslDateTime (in
sal/inc/osl/time.h).
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
