[ODBC-17] Many problem with the MariaDB ODBC Driver Created: 2014-11-19  Updated: 2016-04-18  Resolved: 2016-04-18

Status: Closed
Project: MariaDB Connector/ODBC
Component/s: None
Affects Version/s: 1.0.0
Fix Version/s: 1.0.6

Type: Bug Priority: Major
Reporter: Olivier Bertrand Assignee: Lawrin Novitsky
Resolution: Fixed Votes: 3
Labels: None
Environment:

Windows 7



 Description   

Connection crash:
This driver cannot be tested with the Microsoft ODBC test programme ODBCTE32.EXE.
Trying to connect crashes the program.

ODBC V2 compliance:
Some SQLGetInfo info types are not supported:

  • SQL_ODBC_API_CONFORMANCE
  • SQL_ODBC_SQL_CONFORMANCE

These types are deprecated for ODBC V3 but it is recommended to implement them to be complying with ODBC V2 applications.

Not zero terminated result string:
When using the function SQLColumns the type name is returned as a not zero terminated string.
Of course these functions do not guaranty that result strings are zero terminated but this was the case for almost all drivers including the MySQL ODBC Driver. Besides, this driver returns zero terminated strings for all items except the type name. Not friendly for application writers.

Catalog functions ignore the passed schema parameter:
When calling functions SQLColumns, if a database (schema) is defined in the data source or the connection string, it is used whatever schema name is passed as the function schema argument.

This is also true for SQLTables but in addition, if no default database is defined, the function always returns zero lines.

Misplaced information:
In the result set returned by catalog functions, the schema name is returned in the catalog name column.



 Comments   
Comment by Danny Read [ 2015-02-07 ]

I think my symptoms match this issue.

Strangely/IMPORTANTLY! Now that I have also installed MariaDB 10.0.16 on my PC, I cannot repeat this problem!

But before doing that install, here's what I saw multiple times, and also had a colleague replicate on his similar hardware:

I am on Windows 7 Enterprise, Service Pack 1 (and have MS Office, 32-bit).
I downloaded and installed the ODBC Connector, 1.0.0, 32-bit. (using .msi file), built Jan. 29, 2015.
Then I use the 32-bit ODBC Administrator tool
(C:\Windows\SysWOW64\odbcad32.exe) to add a DSN,
I enter a Name and Description for the DSN, and click Next.
Then I enter the TCP/IP connection info for my server (and port, user, password),
and click "Test DSN".
It displays a pop-up window with the MariaDB version info (10.0.10) from the linux server which hosts the database.
But when I then click anywhere else in the window (for example, try to select from the "Database" drop-down menu), the whole ODBC Administrator tool crashes.

The older 0.9.1 version (of the 32-bit .msi file) installs cleanly
(both versions have a separate error where character fields get truncated [maybe the first half of each value is shown?] during import into Excel or Access, but numbers and date-times are preserved).

The MySQL 5.3.4 connector does not have either of these problems, so my workaround is to use it.

A related mystery, before installing MariaDB, when I tried to "Uninstall" any of the 3 connectors, the windows uninstaller complained that it could not find the uninstall log
(so I ended up manually deleting the files and cleaning the registry of all "MariaDB" references). But now the uninstall seems to be working.

Comment by Lawrin Novitsky [ 2015-02-07 ]

Danny, thanks for your feedback!

The first problem you mentioned, is different from the one described in this issue. And it is already fixed in the repository(https://github.com/MariaDB/mariadb-connector-odbc), and will be released in the next 1.0 release.

Could you please elaborate on the 2nd problem you faced - truncated strings in excel/access. Or maybe even file the bug report here?

Thank you in advance!

Comment by Danny Read [ 2015-02-07 ]

OK, I have created ODBC-18

Comment by Doug [ 2015-03-28 ]

I had an similar experience configuring in Win7 32-bit ODBC. Crashes every time I 'test' connection. I configured without testing, worked only halfway. Tested in two applications. MS Word was able to use in that configuration, sort of. Dropped many mail merge fields, I suspect it was the ones with data containing line endings i.e., '\n' or double backslashes. Basically, probably does not like backslashes, which are necessary for the desired application. LibreOffice Base was able to detect the connection but failed to load tables or pop up any errors explaining why.

In Win7 64-bit, no ODBC administrator issues but Word mail merge failed completely along the lines of the well-documented missing-schema error from Word-2003, but the workarounds for that issue were ineffective (as I am using Word 2010). Basically, instead of loading the fields from the table, it loaded two blank rows with fields I think '__m' and '___m1' or somthing like that. Base failed to use with errors, failed to load tables.

So in short, the ODBC driver works enough to demonstrate that it was installed, but that is pretty much it.

MySQL ODBC driver worked without problem in both environments, I think ANSI 32-bit.

Comment by Doug [ 2015-03-28 ]

Using MariaDB 10.0.13 on recent version of Windows server 64-bit.

Comment by Lawrin Novitsky [ 2015-03-28 ]

Doug, Thank you for your information, but could you please also specify the version you used?
"Test" button crash has been fixed in the repo, other things require investigation. And probably separate bug report

Comment by Lawrin Novitsky [ 2016-04-18 ]

I have just verified that the last issue from this report, that I remember had not been fixed - not NULL terminated strings, is fixed by now.
catalog-schema are switched for "historical reasons". That is how MySQL's ODBC Connector treats "catalog" and "schema". I actually think it should be other way around - MariaDB/MySQL database is schema, and schema should be schema in ODBC. The only way to have it is to make catalog functions behavior depending on designated connection string option, I think.
I will add separate feature request for that.

Generated at Thu Feb 08 03:25:37 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.