Bug 45881 - Database: incorrect support of INTEGER values in Firebird db
Summary: Database: incorrect support of INTEGER values in Firebird db
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Lionel Elie Mamane
URL:
Whiteboard:
Keywords:
: 67144 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-02-10 03:26 UTC by sasha.libreoffice
Modified: 2018-06-24 07:07 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
backtrace of crash in 3.5.0 rc 3 on Fedora 64 bit (21.95 KB, text/x-log)
2012-02-10 03:30 UTC, sasha.libreoffice
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2012-02-10 03:26:02 UTC
I have connected to Firebird using ODBC. Name of database is employee.fdb, password is masterkey, user is sysdba
This database installs with Firebird
LibreBase opened database, but when I attempt to execute this:
select * from "COUNTRY";
Result of executing of this statement in 3.5.0 rc 3 is wrong: instead of some values appears squares, when scroll result by mouse, all disappears.

If try open tables of database, some tables seen wrong, table "employee" crashes 3.5.0 rc3.

If try master 97fdf02-9eed775-f061262, it silently exits writing on console:
Exited with code '139'

used Fedora 64 bit
Comment 1 sasha.libreoffice 2012-02-10 03:30:06 UTC
Created attachment 56857 [details]
backtrace of crash in 3.5.0 rc 3 on Fedora 64 bit
Comment 2 Lionel Elie Mamane 2012-02-10 23:24:00 UTC
That's a driver bug. The driver uses the C/C++ dataype "long" for the SQL datatype "Integer" and for ODBC C type identifier SQL_C_SLONG. It should use the ODBC C typedef of SQLINTEGER for that, which depending on platforms will be "int" or "long" or even (theoretically) something else.

Integer / SQL_INTEGER / SQL_C_SLONG / SQLINTEGER is a 32 bit integer.
On Windows (32 bit or 64 bit), long == int == 32 bit integer, so one can use "long" or "int" interchangeably and the bug does not appear.
On most modern 32 bit Unices, long == int == 32 bit integer, so again the bug does not appear.
On most modern 64 bit Unices, int == 32 bit integer and long == 64 bit integer, so not the same one => need to use the right one.

That's why UnixODBC has:

#if (SIZEOF_LONG_INT == 8)
typedef int             SQLINTEGER;
#else
typedef long            SQLINTEGER;
#endif

See also
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms714556%28v=vs.85%29.aspx
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms713979%28v=vs.85%29.aspx
Comment 3 sasha.libreoffice 2012-02-11 01:05:06 UTC
Thanks for information
Comment 4 Lionel Elie Mamane 2014-12-29 11:37:29 UTC
*** Bug 67144 has been marked as a duplicate of this bug. ***
Comment 5 Alex Thurgood 2014-12-31 11:33:03 UTC
Changed title to better reflect behaviour
Comment 6 Alex Thurgood 2014-12-31 11:36:27 UTC
re-read behaviour and Lionel's comments, re-corrected title
Comment 7 Julien Nabet 2018-06-24 07:07:17 UTC
Just for information, I downloaded 2.0.5 source of Firebird odbc (https://firebirdsql.org/en/odbc-driver/)
Here are the results of grep:
- searching SQL_C_SLONG
=>
...
OdbcJdbc/Headers/SQLEXT.H:493:#define SQL_C_SLONG      (SQL_C_LONG+SQL_SIGNED_OFFSET)    /* SIGNED INTEGER  */
...

- Searching SQL_C_LONG
=>
...
OdbcJdbc/Headers/SQLEXT.H:452:#define SQL_C_LONG    SQL_INTEGER          /* INTEGER
...

Where is the wrong ref to long type?