https://bugs.freedesktop.org/show_bug.cgi?id=50575
Heinz Repp <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #1 from Heinz Repp <[email protected]> 2012-06-06 08:36:17 PDT --- Thank you for picking this up! My thoughts about it: There is nothing wrong with Base and ODBC having different timestamp definitions - after all, Base strives to be able to use many different sources and can not adapt its internal data types to every possible source. So, leaving Base's timestamp precision at hundredths of a second seems reasonable to me. What is needed is a suitable translation layer from driver data types to Base data types and vice versa. The ODBC specification is pretty clear in this aspect. The C Data Types, those that are passed to Base, have ( http://msdn.microsoft.com/en-us/library/windows/desktop/ms714556%28v=vs.85%29.aspx ): SQL_C_TYPE_TIMESTAMP[c] SQL_TIMESTAMP_STRUCT struct tagTIMESTAMP_STRUCT { SQLSMALLINT year; SQLUSMALLINT month; SQLUSMALLINT day; SQLUSMALLINT hour; SQLUSMALLINT minute; SQLUSMALLINT second; SQLUINTEGER fraction;[b] } TIMESTAMP_STRUCT;[a] with note [b]: The value of the fraction field is the number of billionths of a second and ranges from 0 through 999,999,999 (1 less than 1 billion). For example, the value of the fraction field for a half-second is 500,000,000, for a thousandth of a second (one millisecond) is 1,000,000, for a millionth of a second (one microsecond) is 1,000, and for a billionth of a second (one nanosecond) is 1. --- end of ODBC specs --- So _every_ ODBC driver, not just sqlite[3]odbc, is expected to deliver and receive nanoseconds. The wrapper between Base and ODBC has to: - multiply hundredths of a second with 10^7 to be stored in struct tagTIMESTAMP_STRUCT.fraction - divide by 10^7 when reading tagTIMESTAMP_STRUCT.fraction to receive hundredths of seconds. This way all values written by Base can be read and used without issue. Problems arise only with third party data that are more precise than Base's internal data type. This can happen with any database driver, not just ODBC. When those data are used as primary key, Base has no way to address one specific row because its internal representation lacks essential data. This cannot be solved. In this bug the situation is much simpler. The timestamps in my tables are have no fractions of seconds, so the fraction structure element is always 0. My guess is, that Base is failing in translating ODBC timestamps to Base timestamps and/or vice versa. -- 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
