You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Greetings. Thanks for so useful for many people driver. It works good in almost all situations. But in one situation appears problem:
in Libre Base on Fedora 64 bit contents of some tables appears corrupted, with other tables Base crashes.
Resolution of expert:
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
Submitted by: Sasha (sasha)
Greetings. Thanks for so useful for many people driver. It works good in almost all situations. But in one situation appears problem:
in Libre Base on Fedora 64 bit contents of some tables appears corrupted, with other tables Base crashes.
Bugreport about this in LibreOffice bugtracker: https://bugs.freedesktop.org/show_bug.cgi?id=45881
Resolution of expert:
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
-----------------------end of cite--------------------------------------------------------------------------------------
some additional information about my experiments: https://bugs.freedesktop.org/show_bug.cgi?id=34432
The text was updated successfully, but these errors were encountered: