ODBC call failed - Random date overflow errors after moving from 32-bit ODBC 5.1 to 64-bit 5.3 - mysql

Background:
Legacy code running in MS Access 2003.
Sqls run by CurrentDB in Access.
Currently running on Windows 7 32-bit machine.
Connecting to MySQL Server 5.5 through a ODBC 5.1 Driver.
Problem:
Trying to migrate to Windows server 2012 64 bit.
ODBC 5.3 Unicode Driver (32 bit).
Don't want to use time rewriting everything as there is a lot of code, and it will in a not to distant future be removed.
Issue:
Several sql statements fail when running on the new servers. Worked on old servers.
All the failed sqls have now() in the statement.
Error description says ODBC call failed. While the more detailed description says date overflow - "[MySQL][ODBC 5.3(w) Driver][mysqlid-5.5.28-log]Date overflow".
Happens randomly, and when it happens and Access stops one can usually just choose continue and the sql will then work. It fails less than 1% of the times it runs (of thousands).
The only dates in the sql are in the where clause: "and fieldA > now()", where fieldA is a datetime column. This is a get recordset sql. Another error during an insert is the same, but where an integer was subtracted from now() before compared to a datetime.
I don't understand why it says date overflow when there doesn't seem to be a reason for the time of either datetime or "now" to be removed? And since the datetime field is already in the database and now() will get current date and time there shouldn't be any invalid dates?
Any help in what the problem might be or how to debug/log anything that might help would be highly appreciated.
Turning trace on in the ODBC driver is not an option because it happens so randomly, there is so much traffic therefore this would slow down everything such that nothing happens.
Note that I also did encounter one sql where the date overflow error message was correct. It seems that prior to 5.3 when inserting a datetime into a date field it was automatically truncated, because a sql which had been successfull 3000 times started failing. Therefore this sql has been fixed by extracting the date from the field first. But the other errors must be something different.

New version containing a bugfix has been released by Oracle: 5.3.8
This error was a bug that seems to have been introduced in version 5.1.11.
In advanced options there is now a Date overflow check box which has to be ticked for the code to continue when there is an error.
Reply from Oracle about the fix:
"For your information the fix approach was that in C or C++ it is possible to read or write DATE type using SQL_TIMESTAMP_STRUCT.
This struct can hold both date and time.
The error (Date overflow) was generated when with operations that are supposed to be DATE-only this struct got non-zero values for time.
That is the canonical approach as ODBC API requires, however, it causes inconveniences sometimes when for instance the app did not bother
to initialize the whole structure with 0 values because it knows it will only need the DATE part but the random values for TIME fraction could cause the errors despite of being truncated.
A new option was introduced to continue with the query execution rather then return error.
The server will ignore the TIME part and the result is the same as if there were zeroes."

This appears to be an issue with MySQL Connector/ODBC versions 5.2 and later. A web search led to this thread on another site, which in turn led to this unresolved bug report. Note that this is a broader MySQL Connector/ODBC issue; it is not specific to Access applications.
MySQL Connector/ODBC 5.1.13 is still available for download, so your most expedient solution would probably be to simply use that version until the code in question is taken out of service. Your other alternatives might include:
using a newer version of MySQL Server (with [better?] support for fractional seconds), or
tweaking the Access SQL queries to use something other than the Now() function (which you, understandably, would like to avoid).

I had exactly the same problem - "Date overflow" error when saving the data in an Access form.
I changed the data type from "datetime" to "timestamp" in the linked MySQL table and this solved the issue. The datetime data type seems to be too short to accommodate the value of Now() in MS Access.
Remember to refresh the linked tables in Access afterwards.
I also noticed that there was a "Not Null" tick mark next to the ModifyTime timestamp field in the MySQL table. I unticked this.
After these two changes I no longer get the Date Overflow error when Me.Dirty=False executes in Access.
I use Access365 (x64), MySQL ODBC Connector 8.0.31 (x64) and MySQL 5.6

Related

date() and now() functions no longer working in query criteria

I have looked into the references and do not see any libraries with "MISSING" at the end (see image below).
I unchecked and checked the references above that are in use, and that didn't change anything. I then tried to compile the database, and that didn't resolve the issue. I also tried creating a new database and importing all tables, queries, etc. but ran into an error that states "one or more of the newly created objects contain a data type that isn't compatible with earlier versions of access." Is it possible that this is due to updating to datetime2 from datetime? I believe I accepted that change when creating date fields in the Microsoft SQL server management studio.
update: now it appears any criteria associated with using dates is not working. I can't even run a query with the following criteria on a date field:
Between [start_date] And [end_date]

Migrating Microsoft SQL Server to MySQL: Odd errors I can't find documentation or fixes for, including "text is too long"

I have a database in SQL Server that I am trying to convert into a MySQL database, so I can host it on AWS and move everything off-premises. From this link, it seems like normally this is no big deal, although that link doesn't seem to migrate from a .bak file so much as from your local instance of SQL Server that is running and contains the database in question. No big deal, I can work with that.
However when I actually use MySQL Workbench to migrate using these steps, it gets to the Bulk Data Transfer step, and then comes up with odd errors.
I get errors like the following:
ERROR: OptionalyticsCoreDB-Prod.UserTokens:Inserting Data: Data too long for column 'token' at row 1
ERROR: OptionalyticsCoreDB-Prod.UserTokens:Failed copying 6 rows
ERROR: OptionalyticsCoreDB-Prod.UserLogs:Inserting Data: Data too long for column 'ActionTaken' at row 1
ERROR: OptionalyticsCoreDB-Prod.UserLogs:Failed copying 244 rows
However the data should not be "too long." These columns are nvarchar(MAX) in SQL Server, and the data for them is often very short in the specified rows, nothing that approaches the maximum value for an nvarchar.
Links like this and this show that there used to be, almost a decade ago, bugs with nvarchar formats, but they've been fixed for years now. I have checked and even updated and restarted my software and then computer - I have up-to-date versions of MySQL and MySQL Workbench. So what's going on?
What is the problem here, and how do I get my database successfully migrated? Surely it's possible to migrate from SQL Server to MySQL, right?
I have answered my own question... Apparently there IS some sort of bug with Workbench when translating SQL Server nvarchar(MAX) columns. I output the schema migration to a script and examined it, it was translating those columns as varchar(0). After replacing all of them with TEXT columns, the completed migration worked.
Frustrating lesson.

MySQL > SSMS 2012 Linked Server "Requested conversion is not supported."

This little gem has kept me going for a wee while now and I'm still not much further forward.
Environment
SSMS 2012 SP1 (target) (Server 2012 64 bit)
MySQL (source)
Linked server using ODBC 5.3 64bit Unicode driver
I am trying to port the tables from MySQL onto SSMS.
A majority of the tables work fine....until I hit a column that is cast > 8000 chars.
As I was having an issue I tried to just select the offending Columnm
Running a simple
SELECT RogueCol FROM LinkServer...MyTbl
returns the error
OLE DB provider "MSDASQL" for linked server "LinkServer" returned message "Requested conversion is not supported.".
Msg 7341, Level 16, State 2, Line 1
Cannot get the current row value of column "[MSDASQL].RogueCol" from OLE DB provider "MSDASQL" for linked server "LinkServer".
So I then tried
SELECT * FROM OPENQUERY(LinkServer, 'SELECT RogueCol FROM MyTbl')
This returns the same error
I'm totally confused as I cannot seem to even view the data in SSMS, let alone SELECT it into a table (I have a script that will cast the fields according to some rules based on their original MySQL castings)
As I say, for a majority of other fields its not an issue.
The MySQL casting of the RogueCol is varchar(32767)
The settings enabled on the MSDASQL Provider is:
Nested Queries
Level Zero Only
Allow Inprocess
Supports 'Like'
So far I've tried a raft of things which I've 'discovered' on various forums including:
CASTING, CONVERTING, LEFT, LTRIM(RTRIM()) on the actual call.
Tried also restricting it to a TOP 1 record (LEN = 45, Doesn't have any white space or foreign characters in the string)
Set up the ANSI version of the ODBC driver
Various settings within the ODBC driver (Allow Big Result sets, changing Character sets, Limit Columns to 32 bit, Pad char with space among others)
Can I call upon your collective knowledge and request some further suggestions please as this driving me nuts?
Many thanks
UPDATE
So guys and girls, no responses
I ended up having to talk to the DBA responsible for the MySQL DB and asked him to alter the casting of the RogueCol from varchar(32767) to TEXT
Job jobbed

How do you coerce float values in MySQL for classic ASP scripts?

I have been charged with maintaining a legacy classic ASP application. The application uses an ODBC system DSN to connect to a MySQL database.
We had to recently update the servers to satisfy some licencing requirements. We were on Windows, with MySQL 4.x and the 3.51 ODBC driver. We moved to a Linux machine running MySQL 5.1.43 and are running the 5.1.6 ODBC driver on the new IIS server.
Users almost instantly started reporting errors as such:
Row cannot be located for updating.
Some values may have been changed
since it was last read.
This is a ghost error, and the same data changes, on the same record, at a different time won't always produce the error. It is also intermittent between different records, as in, sometimes, no matter what values I plug in, I haven't been able to repro the defect on all records.
It is happening across 70 of about 120 scripts, many over 1,000 lines long.
The only consistency I can find is that on all of the scripts that fail, they are all reading/writing floats to the DB. Fields that have a null value don't seem to crash, but if there is a value like '19' in the database (note the no decimal places) that seems to fail, whereas, '19.00' does not. Most floats are defined as 11,2.
The scripts are using ADODB and recordsets. Updates are done with the following pattern:
select * from table where ID =
udpdated recordID
update properties of the record from the form
call RecordSet.Update and RecordSet.Close
The error is generated from the RecordSet.Update command.
I have created a workaround, where rather than select/copy/update I generate an SQL statement that I execute. This works flawlessly (obviously, an UPDATE statement with a where clause is more focused and doesn't consider fields not updated), so I have a pretty good feeling that it is a rounding issue with the floats that is causing a mis-match with the re-retrieval of the record on the update call.
I really would prefer NOT re-writing 100's of these instances (a grep across the source directly finds 280+ update calls).
Can anyone confirm that the issue here is related to floats/rounding?
And if so, is there a global fix I can apply?
Thanks in advance,
-jc
Have a look at MySQL Forums :: ODBC :: Row cannot be located for updating.
They seem to have found some workaround and some explanations as well..
I ran into a similar issue with a VBA macro utilizing 4.1. When upgraded to 5 errors started popping up.
For me the issue was that values being returned to VBA from MySQL was in a unhandled (by VBA) decimal format.
A CAST on the numbers when querying helped to fix the issue.
So for your issue perhaps the ODBC/ASP combination is recording/reading values differently then what you might expect them to be.

MySQL Field Length Errors

Just moved a site over to a new server and we started getting some errors. Mainly that some data we were passing into a MySQL table was too long for the field. Having checked through the DB it seems the old server was truncating the data to fit the table, yet the new server throws a TEP STOP. Any ideas what the setting is to switch this back on, to temporarily get stuff working again?
Thanks!
MySQL used to be famous/infamous for silently "correcting" data it could not store directly (overlong strings, invalid dates) etc.. That has fortunately changed in recent versions.
You can now configure this behaviour using "Server SQL Modes". You probably want to switch off STRICT_ALL_TABLES or STRICT_TRANS_TABLES.
See MySQL's docs for details.