[ODBC-301] Wrong Query Send by ODBC Driver 03.01.10.00 Created: 2021-01-26  Updated: 2021-04-15

Status: Open
Project: MariaDB Connector/ODBC
Component/s: General
Affects Version/s: 3.1.11
Fix Version/s: 3.1

Type: Bug Priority: Major
Reporter: Piet Assignee: Lawrin Novitsky
Resolution: Unresolved Votes: 0
Labels: ODBC, access
Environment:

Win x64 Access 2016



 Description   

Hi,

I debugged the query which is send via ODBC Driver 03.01.10.00 (Access 2016 application) to my MariaDB 10.5 on FreeBSD.

On every field which is TIMESTAMP or DATETIME or DATE, the ODBC Query is like

 

Execute UPDATE `tblBaustellenDaten` SET `Arbeitsbeginn`=TIMESTAMP'2021-01-26 10:00:00' WHERE `BaustellenDaten_ID` = 13010 AND `Stempel` = TIMESTAMP'2021-01-26 17:25:27'

The leading 'TIMESTAMP' creates fails on INSERT / UPDATING, of course, the server expects a Date and not the string 'TIMESTAMP' and the date.

I just installed the latest mysql odbc connector and it works flawless.



 Comments   
Comment by Lawrin Novitsky [ 2021-01-26 ]

Thank you for your report. I would be surprised, if c/odbc added that to the query. I'd imagine that is done by Access. The question why it does that. It still may be some bug in the connector, or connector should be able to deal with that syntax. Anyway, it's our responsibility to do something about it.
Is it TIMESTAMP in asterisks, that result in bold text here, or just TIMESTAMP, and you added asterisks to emphasize it?

Comment by Piet [ 2021-01-27 ]

I bolded the text. The query is the exact query, which came from access / odbc. In the original query are no asterisks

Comment by Lawrin Novitsky [ 2021-01-28 ]

This is SQL standard syntax, and 10.5 server supports it.
You can try yourself a short test

CREATE TABLE IF NOT EXISTS tt (id int, val DATETIME);
INSERT INTO tt VALUES (1, TIMESTAMP'2021-01-26 10:00:00');
SELECT * FROM tt;
UPDATE tt set val = TIMESTAMP'2021-01-26 10:10:10' WHERE id = 1;
SELECT * FROM tt;

There must be something else. Where did you get thos queries from? Server log or ODBC trace? What is the reported error exactly?

Comment by Piet [ 2021-01-28 ]

This is from my general.log.

My client is Access 2016 with latest ODBC-Driver.
The MySQL-ODBC-Driver does not send the TIMESTAMP string before the date.
Anyway - the server puts NULL into it, with the query, again: the same query with MySQL-Driver works as expected (without TIMESTAMP string)
The field data type ist DATETIME.

Comment by Jérôme Crevecoeur [ 2021-04-11 ]

Hi, i have the same problem...

With maria ODBC and Ms Access, the date are prefixed with 'timestamp'.

If we want null Time, the update don't work:

UPDATE `data argos` SET `nais pra`=TIMESTAMP'1966-07-09 00:00:00' WHERE `num foyer` = 1547;
/* Lignes affectées : 0 Lignes trouvées : 0 Avertissements : 0 Durée pour 1 requête : 0.000 s */

UPDATE `data argos` SET `nais pra`=TIMESTAMP'1966-07-09 15:00:00' WHERE `num foyer` = 1547;
/* Lignes affectées : 1 Lignes trouvées : 0 Avertissements : 0 Durée pour 1 requête : 0.000 s */

Comment by Lawrin Novitsky [ 2021-04-11 ]

crevecoeurj Could you please provide the structure of the table in question? at least involved fields(i.e. `nais pra`). But basically MariaDB server iirc since 10.4 should support this syntax. I could insert TIMESTAMP'1966-07-09 00:00:00' into datetime or time field, with timestamp both your values do not work for me

Can anybody provide ODBC trace for the issue you face?

Comment by Lawrin Novitsky [ 2021-04-11 ]

hevilp if you could also provide ODBC trace with MySQL's driver, that could help.

What is strange, is that the syntax should work with the server.

Thanks all for the help.

Comment by Jérôme Crevecoeur [ 2021-04-13 ]

I'll prepare that soon ... sorry for the delay

Comment by Lawrin Novitsky [ 2021-04-15 ]

I have tried with Access in Office 2019 to input data to datetime fields in the linked table - it uses in both cases(to insert and to update) prepared statements. All works. I can try to get Office 2016, but getting the trace from you could really help.

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