Bug 45881

Summary:	Database: incorrect support of INTEGER values in Firebird db
Product:	LibreOffice	Reporter:	sasha.libreoffice
Component:	Base	Assignee:	Lionel Elie Mamane <lionel>
Status:	RESOLVED NOTOURBUG
Severity:	normal	CC:	iplaw67, lionel, robert, sasha.libreoffice, serval2412
Priority:	medium
Version:	3.5.0 release
Hardware:	x86-64 (AMD64)
OS:	All
See Also:	https://bugs.freedesktop.org/show_bug.cgi?id=67144
Whiteboard:
Crash report or crash signature:		Regression By:
Attachments:	backtrace of crash in 3.5.0 rc 3 on Fedora 64 bit

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?