I am using MySQL Workbench 8.0. I am trying to dump test data to DB including all the tables, stored procedures and views with data.
When I try to import it's says import finished with one error and the error is
Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER'
Operation failed with exitcode 1
Also after importing if I check the database, only tables have come but there are no stored procedures at all.
How would one fix this?
I recently had this problem as well after exporting my database from MySQL Workbench 6.1 CE and then trying to import it into a newer version of MySQL WorkBench 8.0.11. Each were installed with the community server installer msi.
After doing some searching I came across this bug report on the MySQL website:
Restaure dump created with 5.7.22 on 8.0.11
What fix worked for me was to go through my dump file manually and remove the statements:
'NO_AUTO_CREATE_USER' which are located above each of your routine dumps within the dump file.
Statement to remove image example
After I did this I received the error
ERROR 1418 (HY000) at line 318: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable)
But after referring to this answered question:
This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled
and simply entering:
SET GLOBAL log_bin_trust_function_creators = 1;
in the
MySQL command line client solved that issue and finally allowed me to properly import my database with all the dumped tables, data, routines, and functions.
Hopefully this saves others some time.
Best way to find & replace.
Find NO_AUTO_CREATE_USER and replace it with nothing without opening the file.
Linux sed utility is the best option for that if the *.sql file is large to open.
sed -i 's/FIND_TEXT/REPLACE_TEXT/' file.sql
sed -i 's/NO_AUTO_CREATE_USER//' file.sql
-i for --in-place[=SUFFIX]
-s for --separate
I too faced the similar problem. Just removed that words NO_AUTO_CREATE_USER from the import script by using find & replace option in mysql workbench and it executed fine.
Bugs Fixed
Important Change: Importing a dump from a MySQL 5.7 server to a server running MySQL 8.0 often failed with ER_WRONG_VALUE_FOR_VAR when an SQL mode not supported by the 8.0 server was used. This could happen frequently due to the fact that NO_AUTO_CREATE_USER is enabled by default in MySQL 5.7 but not supported in MySQL 8.0.
The behavior of the server in such circumstances now depends on the setting of the pseudo_slave_mode system variable. If this is false, the server rejects the mode setting with ER_UNSUPPORTED_SQL_MODE. If pseudo_slave_mode is true, the server ignores the unsupported mode and gives a warning. Note that mysqlbinlog sets pseudo_slave_mode to true prior to executing any SQL. (Bug #90337, Bug #27828236)
Source: MySQL release notes.
Verifying this:
I connected to MySQL then with my schema selected by default I ran the following commands in a Workbench SQL tab:
SET pseudo_slave_mode = true;
SET ##SESSION.pseudo_slave_mode = true;
To make sure it worked I verified it with other command in other tab:
SHOW VARIABLES;
It showed to me the list of variables and I filtered it typing ps to find the pseudo_slave_mode variable
Yup pseudo_slave_mode was ON now (when previously was OFF)
Then I ran the .sql and it showed me the NO_AUTO_CREATE_USER error again but this time it created everything that was required in the .sql file
Then I dumped the schema, to another sql file to verify it:
mysqldump -u root -p --no-data --routines my_database > schema.sql
Everything was ok. This time it dumped it with a modified sql_mode
I hope this can be helpful for you.
I found a workaround, if not the solution. Use Linux to get the sed utility, and run the two sed commands as mentioned in my previous comment. Also, I needed to use the mysqldump option: --set-gtid-purged=OFF
From the command line, the --force option will cause mysql to continue processing the dump and ignore the 'NO_AUTO_CREATE_USER' (as well as any other) error.
You can turn on this behavior in MySQL Workbench as well. See Continue SQL query even on errors in MySQL workbench.
Dillon's answer works for me, thanks
MAC OS:
sed -i old 's/\DEFINER=[^]*#[^]*//g' file_name.sql
sed 's/,NO_AUTO_CREATE_USER//g' -i file_name.sql
LINUX:
sed 's/\sDEFINER=[^]*#[^]*//g' -i file_name.sql
sed 's/,NO_AUTO_CREATE_USER//g' -i file_name.sql
Mysql:
mysql> SET GLOBAL log_bin_trust_function_creators = 1;
Worked for me when I downgraded the mysql, to more compatible version.
Probably would've also work to update the driver.
I just ran into the same exact problem while restoring a 5.7 version dump using Workbench 8.0 in Windows environment.
I combined everyone's recommendations above as follows:
Used Notepad++ and to universally remove the "NO_AUTO_CREATE_USER" option from the dump file.
SET pseudo_slave_mode = true;
SET ##SESSION.pseudo_slave_mode = true;
SET GLOBAL log_bin_trust_function_creators = 1;
That worked (Thank you), however - some important notes:
usage of special characters (i.e. double-quotes, back-slashes, etc.), if not properly formatted can cause the debugger to flag it, thus aborting the import.
deprecated commands, such as "reset query cache" will also cause the debugger to throw an exception.
Any of the above is typically exhibited as: ERROR 1064 (42000) at line : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near <...>
I handled each condition by copying the individual problematic stored procedure from the dump file into a NEW stored procedure in Workbench. The native debugger immediately highlighted the offending line(s)/statement(s).
After several volleys of the above, I was able to finally import the entire .sql dump file cleanly.
I 've re-installed mysql, uninstalled MAMP.
So currently I should only have one version of mysql.
I've done the following:
Installed phpmyadmin
Created a database
I try to import data to it, but the file is too big so I do it via the command line. But there I dont see my newly created database, furthermore I see less databases.
If I do show databases; on the command it shows:
information_schema
test
It doesnt show my newly created Database and it doesn`t show other databases that were pre-installed, these are the databases that I see on phpmyadmin:
information_schema
mysql
performance_schema
test
myBBDD->the one I just created and I was looking for to import data via command-line
It seems I have two versions of mysql, but if I stop mysql via command line, I then can't access phpmyadmin so I guess it's the same one, but for some reason I can't access the same databases.
If you could throw me a bone on this? Im completely lost.
To install mysql and phpmyadmin I've followed this tutorial
[EDIT]
I tried to delete test and it did dissapear from the command-line too, so it is the same version of MySql, so it must be a permission issue... still investigating
Thanks.
Sounds like you have MAMP's version of MySQL and a standalone MySQL. See this answer:
Access MAMP's MySQL from Terminal
Just had the same issue, in my case it turned out to be that I wasn't logging in as the correct user.
In the command line, instead of running just mysql, try running mysql -u root -p (replace "root" with whatever user you used in phpMyAdmin to set the databases up). You should then be able to type in the password. Check show databases; again.
Just noticed that user Grasshopper in a previous answers' comments was suggesting exactly this, hopefully this will help someone anyway by spelling it out.
On the old server I used the mysqldump command to make me a backup of the MySQL database.
On the new server, with version 5.6 of MySQL, the same command gives me the error
unknown option '-no-beep'
whatever it insert.
I also searched on the internet but I could not find any help....
In your init file for mysql (my.ini), comment out the no-beep line, as it is no longer a valid option in mysql > 5.0.
See answers here
I did an upgrade of Xampp to version 1.8.3-1
In phpMyAdmin, I can see my databases and the tables in them on the list on the left side.
But if I click any of my tables, I get and error #1146 table doesn't exist.
It is probably some kind of user access issue. But I haven't changed anything. I'm logging as root/no pw on mysql.
any idea?
thanks,
Benoit
If you changed the version of XAMPP you also chnaged the version of MySQL.
A straight copy of databases will probably not work.
You either need to backup under the old version and restore into the new version or use the mysql_upgrade processor.
Look up usage of mysql upgrade here mysql doc
You will need to find the page relating to the from-version and to-version of MySQL. It may even be required to go via a number of other versions of MySQL. So the backup and restore option os a lot easier.
Simple upgradation wont help, Following two steps will help you out:
Before upgrade , Go to the directory xampp/mysql/data ( or whatever is relevant to your OS) , and copy all the files starting with word ib, like ib_logfil0 etc. and paste to the upgraded version after upgrade.
Go to mysql command line, and run this command:
mysql_upgrade
originally i was using easyPHP (windows) then i switch to mac and used MAMP.
i archive my db every once in a while and right before i reformatted. The export was made by going into the root of phpMyAdmin and using the export function. Now i am trying to import the data i get this error "#1044 - Access denied for user 'root'#'localhost' to database 'information_schema'". Doing other things i got errors like
"#1146 - Table 'test_db.COLLATION_CHARACTER_SET_APPLICABILITY' doesn't exist", "#1146 - Table 'test_db.CHARACTER_SETS' doesn't exist " and "#1146 - Table 'test_db.COLUMNS' doesn't exist" and "#1046 - No database selected"
How do i get MAMP to import and ignore any access errors and continue so my DB is filled to the previous state? I rather not write an app to do this but if i had to what libs would i use to parse the sql statements in the sql dump? It doesnt look hard to parse. It looks like a semicolon separates the statements. But what about escape and unescape issues? how do i handle that?
The first error indicates that something is very wrong with your setup. information_schema is an internal DB which keeps data about other parts of the system (meta-data). You should try reinstalling your MySQL server (or even MAMP as a whole).
Second of all: the dump files can be imported using the mysql command line client like this:
mysql -p -u root test_db < dump.sql
One thing to remember is that "test_db" needs to be created before the dump is restored. An other possible problem might be that the dump/restore is being done by different versions of MySQL (ie. 5.0 vs 5.1). For this you could try the --force command in the mysql command line to skip over failed executions, however be aware that this might not correctly restore your data.