dont access pages in mdb_fetch_row when pdata is not initialized.
Happens when a client, e.g. pyodbc, queries for an unsupported type,
e.g. SQL_WVARCHAR, temp_table is empty and further access to it will crash.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff70fe3df in mdb_fetch_row (table=0xa74610) at data.c:467
467 rows = mdb_get_int16(
Backtrace:
0 0x00007ffff70fe3df in mdb_fetch_row (table=0xa74610) at data.c:467
1 0x00007ffff77f8746 in SQLFetch (hstmt=0xa70500) at odbc.c:1074
2 0x00007ffff7729b43 in SQLFetch () from /lib/x86_64-linux-gnu/libodbc.so.2
3 0x00007ffff778d545 in GetColumnSize (cnxn=0x7ffff77eb1f0, cnxn=0x7ffff77eb1f0, psize=0x7ffff77bde00, sqltype=-9) at src/cnxninfo.cpp:81
4 CnxnInfo_New (cnxn=0x7ffff77eb1f0) at src/cnxninfo.cpp:145
Signed-off-by: Ulrich Weber <ulrich.weber@gmail.com>
Per #260 I am assuming that the internal version 6 refers to files
created with Access 2019. I can't find any documentation on this format,
so I am calling it ACE17. Testing welcome.
When searching for unixODBC, we want to use
the libdir passed in to autotools (--libdir)
to ensure that we find the library
for the correct ABI.
It is possible that we pick up the wrong
copy from e.g. /usr/lib/ where a 32-bit
unixODBC copy of the library exists
when we're in the middle of a 64-bit build.
Use ${libdir} to ensure we respect
any preferences/information given and
search for ODBC in the right place.
Note that this previously affected
us with iODBC but that's since been
resolved by using their
iodbc-config binary.
Bug: https://bugs.gentoo.org/697568
Signed-off-by: Sam James <sam@gentoo.org>
* Refactor code so BLOBs are always correctly exported
Previously, BLOBs weren't exported from mdb-export correctly if the
backend had MDB_SHEXP_BULK_INSERT set.
* Export MySQL BLOBs correctly
MySQL BLOBs should be in the form 0x[hex values] when inserting them
with the mysql command line tool.
* MySQL needs a BLOB to store exported MDB_OLE values
MDB_OLE size always comes out as 256 bytes, but varbinary(256) is insufficient
to hold all possible OLE data.
SQLFetch / SQLExtendedFetch now skip the mdb_sql machinery and use
SQLGetData on their bound columns instead. We rely on mdb_fetch_row
to skip to the correct page without any bindings and then SQLGetData will
do the rest.
SQLFetch will now correctly return SQL_SUCCESS_WITH_INFO if one or more
bound columns have their data truncated, and will return several kinds of errors
(provided by SQLGetData) that were previously ignored.
Updated the unit test with a SQL_C_LONG type for demonstration purposes.
Fixes#23
By default this will be set to the C locale, but set it to the user's
locale when string comparisons are performed from mdb-sql. Note that
this can be overridden with the LC_COLLATE environment variable.
We could infer the collation locale from the file itself, but this will
likely require a big ball of glue between the Windows locales and Unix
ones.
* Differentiate character lengths from byte lengths (see #112)
* Use GNU-style indexed initializers for clarity
* Remove needs_quotes since it's not used anywhere
* MDBOPTS=no_memo is not used anywhere; mark deprecated and print a
warning if enabled
* Mark MDBOPTS=use_index as experimental in the man pages
* MDBOPTS need to be colon separated
* Document new long forms of mdb-queries options
