[MDEV-8584] connect engine -> unixodbc -> firebird Created: 2015-08-08  Updated: 2022-09-12  Resolved: 2022-09-12

Status: Closed
Project: MariaDB Server
Component/s: OTHER
Affects Version/s: 10.0.21
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Thomas Assignee: Olivier Bertrand
Resolution: Won't Fix Votes: 0
Labels: connect-engine, firebird, mariadb, unixodbc
Environment:

Centos 7

Attachments: File hostname.err     File odbc.ini     File odbc_firebird.result     File odbc_firebird.test     File odbcinst.ini    

 Description   

I like to use connect engine of mariadb to connect to a firebird database via ODBC on a server which is running on Centos 7.

I have already established a connection to sqlserver.
The odbc-test to the firebird-database with isql works as well.

This is my create-statement for remotetable

CREATE TABLE con.test_table_apys
 
ENGINE=CONNECT
 
TABLE_TYPE=ODBC
 
TABNAME='wsk_lager_st'
 
CONNECTION='DSN=apys;UID=SYSDBA;PWD=myownpassword';

After sending the statement to the server I got this error message:

ERROR 2006 (HY000): MySQL server has gone away

This is the content of odbc.ini

[apys]
 
Description     = Firebird
 
Driver          = Firebird
 
Dbname          = apysdbserver/3051:vm_apys_ori205
 
Role            =
 
CharacterSet    = WIN1252
 
ReadOnly        = No
 
NoWait          = No

But as already mentioned the odbc-connection with isql is working.



 Comments   
Comment by Olivier Bertrand [ 2015-08-13 ]

I have no problem to use Firebird as a data source on Windows 7.

On Linux (ubuntu) I had to install unixODBC, Firebird, the Firebird ODBC driver and recompile MariaDB with CONNECT ODBC supported. Not a piece of cake! Why is this damn Linux making things 100 times more difficult than they are on Windows...

However, after two days I was able to make tests. I mean tests, because some link errors was prevented me to install the new version of MariaDB! But mysql-test was working, so I made an odbc_firebird.test and it did not fail. I will put some files in attachment so you can see what I have done.

Some remarks:
Many failures were problems of permission on files or directories.
The DSN description in odbc.ini must contain the full path of the database file.
isql-fb generally works without problem but isql can have permission problems, the same CONNECT can have.
Even when accessing Firebird by CONNECT failed, this was never crashing the MariaDB server.

Right now, I am unable to reproduce your problem. It can be depending on the environment or on the specific database you are using. Could you please attach the FDB file so I can try it?

Note: Difficult to point out precisely what went wrong from your hostname.err file because it is not a DEBUG built server.

Comment by Olivier Bertrand [ 2015-08-14 ]

I probably found what caused a crash of the server. In some cases, SQLFetch places in the result length variable the value SQL_NO_TOTAL (-4) indicating it cannot found the length. It can happen when using a database where conversion is needed from unicode or UTF8, or when a string column is too big (depending on the driver) or is some types such as blob or text.

Later on, calling SetValue_char with that negative value does crash the server.

I have added a test for the SQL_NO_TOTAL value and added protections in the SetValue_char functions. Of course, even if this probably fix the crash in your case, I cannot be sure of it not able to reproduce the wrong case.

Meanwhile what you can do is not to use the discovery process (in which the crash occurs) but create your table manually defining the columns. You can probably create a catalog table to see what are the columns specifications by:

CREATE TABLE con.test_table_apys_cols
 
ENGINE=CONNECT
 
TABLE_TYPE=ODBC
 
TABNAME='wsk_lager_st'
 
CONNECTION='DSN=apys;UID=SYSDBA;PWD=myownpassword' CATFUNC=columns;

This can show what is the column that causes problem.

Comment by Sergei Golubchik [ 2022-09-12 ]

10.0 was EOLed in March 2019

Generated at Thu Feb 08 07:28:14 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.