I have mysql 5.6.27 installed on my two servers.
Database has a table which has a column type bigint(20) unsigned NOT NULL.
While inserting a string type value (like 1_2_3_4) in this column on one server it storing value 1 and showing a data truncation warning.
But if i am executing the same query on another server it showing the error message for data truncation and not letting the value inserted.
Just trying to understand why mysql is casting the value on one server but not on another.
Sounds like a configuration issue, specifically strict settings, see https://www.davidpashley.com/2009/02/15/silently-truncated/
Related
I've been using the connector for a few years now to push and pull data between a MS SQL Server database and a couple different MySQL databases. I set up a Linked Server, then using OPENQUERY I create the views I need and I write my selects, updates, and inserts against those views. Works like a dream.
However, I'm trying to integrate with a new MySQL database built by a vendor which uses the ENUM datatype, which is causing me trouble.
When I try the OPENQUERY I get a weird error:
OLE DB provider 'MSDASQL' for linked server 'MYSQL_DATABASE' returned data that does not match expected data length for column '[MSDASQL].EnumDataField'. The (maximum) expected data length is 10, while the returned data length is 8.
I can fix this by converting the ENUM field to a CHAR in the query and it works ok.
But now I need to insert or update that ENUM field, and I cannot figure out how to do it. If I convert the datatype on the view, I can't use that view to insert or update.
Is there a way for me to work with ENUM fields through the connector? Especially a way for me to do INSERT or UPDATE of an ENUM value?
I have just created a new MySQL in an AWS Ubuntu instance.
Then I have copied a table from another MySQL server to the new created database.
This is the structure from some fields from one of the tables:
My issue is that every time I try to enter a new record on the table, there is an error at field fecha_recepcion_disp:
I have checked if the original table from where I have copied the table has the same issue, but no, I am able to enter a new record without issues.
What should I check in the new database or table in order to avoid the issue?
EDIT:
The only difference between both servers is that the first one is located in the USA and the second one is located in France.
Issue solved:
The new server had value NO_ZERO_DATE in sql mode variable.
You're surely using different versions. MySQL 5.7+ stopped supporting zero values in the datetime field.
You can either use as default the current timestamp, or put null.
I have three databases that are all meant to be the same but unfortunately are all different versions of Mysql (not my decision and unable to change that currently) only MariaDb 10.4 do I get an error when trying to send all data from a view into a historical table.
INSERT INTO
`destination`.historical_table
SELECT * FROM
`source`.daily_table
There are no triggers and the flagged column has the same datatype CHAR(1) on both tables.
The source table is actually a view, could that be the problem? It works on my other two DBs...
UPDATE: So this was actually my own fault but an interesting issue that mariahdb 10.4.10 caught but mysql 5.6.33 and mariahdb 10.1.38 did not.
The table definitions were not identical, two columns were switched between source and destination causing the failure. On the other databases however they merely truncated the values to the correct size (thus inserting incorrect data as well).
More my fault than anything else but interesting and something to take note of nonetheless.
I have two MySQL instances. The 1st one truncates strings on insert when data is too long. The 2nd one raises an error:
ERROR 1406 (22001): Data too long for column 'xxx' at row 1
I want the 2nd one to truncate the data as well.
Is there any MySQL setting to manage this behavior?
You can disable STRICT_TRANS_TABLES and STRICT_ALL_TABLES. This allows the automatic truncation of the inserted string.
Quote from MySQL Documentation.
Strict mode controls how MySQL handles invalid or missing values in
data-change statements such as INSERT or UPDATE. A value can be
invalid for several reasons. For example, it might have the wrong data
type for the column, or it might be out of range. A value is missing
when a new row to be inserted does not contain a value for a non-NULL
column that has no explicit DEFAULT clause in its definition. (For a
NULL column, NULL is inserted if the value is missing.)
Reference: MySQL Server SQL Modes
If strict SQL mode is not enabled and you assign a value to a CHAR or VARCHAR column that exceeds the column's maximum length, the value is truncated to fit and a warning is generated. For truncation of nonspace characters, you can cause an error to occur (rather than a warning) and suppress insertion of the value by using strict SQL mode. See Section 6.1.7, “Server SQL Modes”.
How you can change it:
http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html
Found two ways to disable strict mode:
add below to my.cnf
sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
way is using mysql console.
SET ##global.sql_mode= '';
Please test them before running on production environment.
if you use cpanel ,
replace
sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
into /usr/my.cnf
to
sql-mode=""
run
/etc/init.d/mysql restart
I have problem with MS Access 2007 table connected via ODBC to MySQL server (not Microsoft SQL Server).
If unique identifier in MySQL table is BIGINT - all cells content is displayed like this: "#Deleted".
I have found this article:
"#Deleted" errors with linked ODBC tables (at support.microsoft.com)
and it says:
The following are some strategies that you can use to avoid this
behavior:
Avoid entering records that are exactly the same except for the unique index.
Avoid an update that triggers updates of both the unique index and another field.
Do not use a Float field as a unique index or as part of a unique index because of the inherent rounding problems of this data type.
Do all the updates and inserts by using SQL pass-through queries so that you know exactly what is sent to the ODBC data source.
Retrieve records with an SQL pass-through query. An SQL pass-through query is not updateable, and therefore does not cause
"#Delete" errors.
Avoid storing Null values within any field making up the unique index of your linked ODBC table.
but I don't have any of these things "to avoid". My problem is in BIGINT. To make sure if this is it I created 2 tables, one with INT id, one with BIGINT. And this is it.
I can't change BIGINT to INT in my production database.
Is there any way to fix this?
Im using: Access 2007, mysql-connector-odbc-3.51.30-winx64, MySQL server 5.1.73.
You can try basing the form on an Access query, and converting the BIGINT to an INT using CInt() in the query. This happens before the form processing. Depending on your circumstance, you may need to convert to a string (CStr()) in the Query, and then manually handle validating a user has entered a number using IsNumeric. The idea is to trick the form into not trying to interpret the datatype, which seems to be your problem.
Access 2016 now supports BigInt: https://blogs.office.com/2017/03/06/new-in-access-2016-large-number-bigint-support/
It's 2019 and with the latest ODBC driver from Oracle (v 8.0.17) and Access 365 (v 16.0.11904), the problem still occurs.
When the ODBC "Treat BIGINT columns as INT columns" is ticked and in Access support for Bigint is enable in options, the Linked tables with Bigint #id columns (the primary key) shows as deleted. Ruby creates these by default, so we are loathe to fiddle with that.
If we disable the above two option, Access thinks the #id column bigint is a string and shows the data. But then the field type is not bigint or int anymore.
This is quite pathetic, since this problem is almost 10 years old now.
The MySQL driver has an option to convert BIGINT values to INT. Would this solve the issue for you?