I created a FEDERATED database on a Centos 7 with MariaDB 5.5.44 from a db located on a Centos 6.x with Mysql 5.1.69.
Updating value for a TEXT column from Centos 7 - MariaDb returns no error but does not update column value.
Update works fine with varchar & int.
Does anyone encoutered this issue and have some information about it ?
Thanks
Nicolas
(copied from comment and prettyprinted...)
CREATE TABLE IF NOT EXISTS session (
session int(11) NOT NULL,
session_name varchar(32) COLLATE latin1_general_ci DEFAULT NULL,
om_utilisateur int(11) NOT NULL,
clef varchar(100) COLLATE latin1_general_ci NOT NULL,
valeur text COLLATE latin1_general_ci NOT NULL,
crea_modi timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (session),
KEY session_name (session_name)
) ENGINE=FEDERATED DEFAULT CHARSET=latin1 CONNECTION='mysql://USER:PASS#prod/utilisation/news';
We have the same problem with a Debian Stretch "mysql Ver 15.1 Distrib 10.1.22-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2" accessing with federated tables to a Debian Wheezy "mysql Ver 14.14 Distrib 5.5.55, for debian-linux-gnu (x86_64) using readline 6.2"
We have not a real solution but two possible workarounds:
update value to NULL or empty string first and save the wanted value afterwards
use big VARCHAR instead of TEXT
A bug like this was reported on the mysql bug site: https://bugs.mysql.com/bug.php?id=34997
Other people speaking about this here: mySql federated table unable to update blob columns
Related
Im using xampp control panel and from there i start the process for apache and mysql. Then i go to mysql workbench and server status seems to be ok, here is some info
Host: Windows-PC
Socket: C:/xampp/mysql/mysql.sock
Port: 3306
Version 10.1.31-MariaDB mariadb.org binary distribution
Compiled For: Win32(32)
Configuratin File: unknown
Then everytime when i try to add the foreign key for my dummy schema like:
ALTER TABLE `puppies`.`animals`
ADD INDEX `Breed_idx` (`BreedID` ASC) VISIBLE;
;
ALTER TABLE `puppies`.`animals`
ADD CONSTRAINT `Breed`
FOREIGN KEY (`BreedID`)
REFERENCES `puppies`.`breeds` (`Breed`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
I get the following error
ERROR 1064: You have an error in your SQL syntax; check the manual that
corresponds to your MariaDB server version for the right syntax to use near
'' at line 2
SQL Statement:
ALTER TABLE `puppies`.`animals`
ADD INDEX `Breed_idx` (`BreedID` ASC) VISIBLE
So what can i do so that xampp will start using mysql syntax over mariaDb?
Or if im wrong in my understanding of the problem, then what should i do so that i dont have to face this kind of issues again when using xampp?
Problem is the word VISIBLE, remove it and it will work.
Index are visible by default.
Your question: "If i remove VISIBLE it works just fine, so why did mysql workbench decided to add visible?"
My answer: The option to mark index invisible is not yet implemented in MariaDB (afaik!).
Update:
The syntax for MariaDB is different, please see this reference: https://jira.mariadb.org/browse/MDEV-7317
Just to add to those who are using Maria DB with MySQL Workbench, you don't need to install mysql. You can just change 'Default Target MySQL Version' from Preferences to 5.7 or 5.6, and the VISIBLE keyword will be removed by workbench.
Here is a link from mysql bugs
https://bugs.mysql.com/bug.php?id=92269
I am using MySQL Workbench and have same problem. Change in the Preferences but it did not work.
Solution: If you export forward-engineer the model you need to change the configuration on another place.
Go to Model > Model Options
Inside the Model Options, go to MySQL
Then change the "Target MySQL Version" to 5.6
Im using xampp control panel and from there i start the process for apache and mysql. Then i go to mysql workbench and server status seems to be ok, here is some info
Host: Windows-PC
Socket: C:/xampp/mysql/mysql.sock
Port: 3306
Version 10.1.31-MariaDB mariadb.org binary distribution
Compiled For: Win32(32)
Configuratin File: unknown
Then everytime when i try to add the foreign key for my dummy schema like:
ALTER TABLE `puppies`.`animals`
ADD INDEX `Breed_idx` (`BreedID` ASC) VISIBLE;
;
ALTER TABLE `puppies`.`animals`
ADD CONSTRAINT `Breed`
FOREIGN KEY (`BreedID`)
REFERENCES `puppies`.`breeds` (`Breed`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
I get the following error
ERROR 1064: You have an error in your SQL syntax; check the manual that
corresponds to your MariaDB server version for the right syntax to use near
'' at line 2
SQL Statement:
ALTER TABLE `puppies`.`animals`
ADD INDEX `Breed_idx` (`BreedID` ASC) VISIBLE
So what can i do so that xampp will start using mysql syntax over mariaDb?
Or if im wrong in my understanding of the problem, then what should i do so that i dont have to face this kind of issues again when using xampp?
Problem is the word VISIBLE, remove it and it will work.
Index are visible by default.
Your question: "If i remove VISIBLE it works just fine, so why did mysql workbench decided to add visible?"
My answer: The option to mark index invisible is not yet implemented in MariaDB (afaik!).
Update:
The syntax for MariaDB is different, please see this reference: https://jira.mariadb.org/browse/MDEV-7317
Just to add to those who are using Maria DB with MySQL Workbench, you don't need to install mysql. You can just change 'Default Target MySQL Version' from Preferences to 5.7 or 5.6, and the VISIBLE keyword will be removed by workbench.
Here is a link from mysql bugs
https://bugs.mysql.com/bug.php?id=92269
I am using MySQL Workbench and have same problem. Change in the Preferences but it did not work.
Solution: If you export forward-engineer the model you need to change the configuration on another place.
Go to Model > Model Options
Inside the Model Options, go to MySQL
Then change the "Target MySQL Version" to 5.6
I have to move Ubuntu mariadb(10.1.41) data(78GB) to CentOS mariadb(5.5.64).
I used to mysqldump and export on heidiSQL, But every try is failed.
I think problem is that column 's default is current_timestamp.
So, I did test.
here is test query:
CREATAE TABLE test (
ts INT(11),
ts2 DATETIME DEFAULT CURRENT_TIMESTAMP
);
Result is
"SQL ERROR(1067) : Invalid default value for 'test'"
So, I tried : edit configure /etc/my.cnf
sql-mode="ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
and
sql-mode=""
and
sql-mode="NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
But, Everything is Failed. what should I do??
In MariaDB 5.5 CURRENT_TIMESTAMP is not supported as default for column type DATETIME.
Workarounds:
Update MariaDB Server to 10.x
change column type from DATETIME to
TIMESTAMP
After I upgraded my MySQL version from 5.6 to 5.7, the AzerothCore installer fails with errors like:
ERROR 1067 (42000) at line 234: Invalid default value for 'last_login'
ERROR 1292 (22007) at line 266: Incorrect datetime value: '0000-00-00 00:00:00' for column 'last_login' at row 1
and:
Can't find any matching row in the user table
In fact, you better do it like this (to avoid removing default modes):
-- Select the sql modes
SELECT ##sql_mode;
-- Remove the 2 modes NO_ZERO_IN_DATE and NO_ZERO_DATE and run this query
SET sql_mode = 'mode_1,mode_2,mode_3,mode_4,mode_5';
Also this can be put directly in mysql configuration.
After [mysqld]:
[mysqld]
sql_mode = mode_1,mode_2,mode_3,mode_4,mode_5
Note: ONLY_FULL_GROUP_BY can be kept
EDIT: As of march 2019, it's probably not needed at all, we have fixed this but it might occur again in the future
EDIT: this answer is a bit outdated, some of the issues with MySQL 5.7 have been resolved in the latest version
As stated in the requirements page of the AC wiki:
AzerothCore does not officially support MySQL version >= 5.7, but there is a way to get it up and running.
You have to remove ONLY_FULL_GROUP_BY,NO_ZERO_IN_DATE and NO_ZERO_DATE flags from MySQL's sql_mode variable in the MySQL config file so that all queries updates and core statements can be applied correctly.
I've found it useful to set my SQL mode to the empty string (which in my case solved all the issues with MySQL 5.7):
SET GLOBAL sql_mode = ''
you can run that sql statement via terminal using:
mysql -e "SET GLOBAL sql_mode = '';"
or alternatively you can manually set the SQL mode before running any SQL statements:
SET sql_mode = '';
One of our MariaDB users decided to copy a database via a shell script that pipes the output of a mysqldump to another table.
If you restore the mysqldump to a database that hasn't been created before, it works just fine. However, if you then drop that database, re-create it, and then try to run the script again, it throws the following error:
ERROR 1005 (HY000) at line 25: Can't create table
core_dev.addresses (errno: 121 "Duplicate key on write or update")
mysqldump: Got errno 32 on write
SHOW ENGINE INNODB STATUS yields the following insight:
2017-05-03 09:34:19 7f9929fb4b00 Error in foreign key constraint
creation for table core_dev.addresses. A foreign key constraint of
name core_dev.addresses_ibfk_2 already exists. (Note that
internally InnoDB adds 'databasename' in front of the user-defined
constraint name.) Note that InnoDB's FOREIGN KEY system tables store
constraint names as case-insensitive, with the MySQL standard
latin1_swedish_ci collation. If you create tables or databases whose
names differ only in the character case, then collisions in constraint
names can occur. Workaround: name your constraints explicitly with
unique names.
However, the core_dev database is entirely empty:
MariaDB [(none)]> SHOW TABLES IN core_dev;
Empty set (0.01 sec)
What could the problem be? I'm not able to replicate this problem on any of our other MariaDB 10.1 servers. The only difference is that this particular one is running on CentOS 6, while the others are on CentOS 7.