CREATE TABLE `revenue_daily` ( `wallet` varbinary(100) NOT NULL DEFAULT '0',
`tc_access` varbinary(100) NOT NULL DEFAULT '0',
`tc_short` varbinary(100) NOT NULL DEFAULT '0',
`total_toll_collection` varbinary(100) GENERATED ALWAYS AS (`wallet` + `tc_access`) VIRTUAL NOT NULL,
`cash_collection` varbinary(100) GENERATED ALWAYS AS (`total_toll_collection` - `tc_short`) VIRTUAL NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=ascii;
That table has generated column.I backed up database structure with data and when i am restoring same .sql file then error occur.
Error is:-
ERROR 3105 (HY000) at line 262: The value specified for generated column 'total_toll_collection' in table 'revenue_daily' is not allowed.
I am using mysql version:-
sunilp#sunilp ~> mysql --version
mysql: [Warning] World-writable config file '/etc/mysql/mysql.conf.d mysqld.cnf' is ignored.
mysql Ver 14.14 Distrib 5.7.18, for Linux (x86_64) using EditLine wrapper
This is a problem when using mysqldump from MariaDB with virtual generated columns.
MariaDB's mysqldump apparently dumps the generated values, but MySQL only accepts DEFAULT as value for a virtual generated column.
It seems like you need to use MySQL's mysqldump to correctly dump and restore virtual generated columns on a MySQL server.
The bug was also reported here.
What I do as a workaround, is replace the virtual column in the dump:
sed -i 's/GENERATED ALWAYS AS .* VIRTUAL/NOT NULL/' mydump.sql
then restore the dump, then drop/add the generated column again:
mysql -e "ALTER TABLE foo DROP COLUMN bar;\
ALTER TABLE foo ADD COLUMN bar VARCHAR(255) AS ...;"
I also posted this answer here.
I had the same problem dumping it from mariadb using adminer (https://www.adminer.org/)
In my case I solved it doing dump with phpmyadmin. It worked for me.
I don't know reason but adminer dump generated values columns. It shouldn't because that value should be generated when rows are inserted.
I didn't try what happens when using mysqldump from command line...
Related
I would like to take a dump from Mysql 8.0.11 and restore it into 5.7.27.
When I tried to restore it I got the error:
ERROR 1273 (HY000) at line 25: Unknown collation: 'utf8mb4_0900_ai_ci'
Then I tried to use the compatible flag to make it easier on an older MySQL DB.
mysqldump --compatible=mysql4 --add-drop-table -u r00t -h xxx.eu-north-1.rds.amazonaws.com -p radius_db > ~/radius.sql
But that doesn't seem to work either:
mysqldump: Couldn't execute '/*!40100 SET ##SQL_MODE='MYSQL40' */':
Variable 'sql_mode' can't be set to the value of 'MYSQL40' (1231)
Any advice would be appreciated.
Simply put, use as a DEFAULT "utf8" and as COLLATE "utf8_general_ci".
One way to solve your problem is to change in your import .sql-Files from
"utf8mb4" to "utf8"
and "utf8mb4_0900_ai_ci" (or something else) to "utf8_general_ci"
Hint: Don't forget to backup your files just in case ;-)
Go to your (.sql) import files and do these changes.
From:
ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8_general_ci;
to:
ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
Reimport again.
You can use the next code to move your database from mysql 8.x to mysql 5.x.
mysqldump db > db.sql
sed -i s/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g db.sql
mysql db < db.sql
db is your database name
I'm running a MySQL 5.1 server under CentOS 6.5. During an import of a SQL file today, all tables were created under MyISAM, even if they were declared to use InnoDB engine.
For example, I had a table declared on the .sql file as this:
CREATE TABLE `customer` (
`customer_id` int(11) NOT NULL AUTO_INCREMENT,
`customer_no` varchar(20) DEFAULT NULL,
`company_name` varchar(50) DEFAULT NULL,
[....]
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=latin1 ROW_FORMAT=COMPACT
When the .sql file was imported using:
mysql -u <username> -p < new_db.sql
The customer table was created using the MyISAM table. How can this be possible?
To fix the issue I have added on MySQL config to set the default engine to InnoDB and restarted but, since the table engine was declared to be InnoDB, shouldn't it be loaded using that declared engine instead of the default ?
MySQL 5.1 have some problems. I prefere to update it.
The other way is to disable different InnoDB settings in your my.cnf until innoDB is running.
show engine innodb status
With this command you can check the current state. Dont forget to restart mysql after every change.
After a long time searching for an explanation of the issue I have found none, but there are ways to prevent the issue and to fix it.
1st - Check this MySQL configuration: no engine substitution. It will help to avoid the issue. http://dev.mysql.com/doc/refman/5.0/en/sql-mode.html#sqlmode_no_engine_substitution
2nd - When the error is happening, use both show_warnings and show_engines to see any errors that occurred and to see if InnoDb is enabled. You can also use show engine innodb status to gather detailed information.
3rd - Since MySQL 5.1 have by default MyISAM as the default engine, set mysql configuration to use InnoDB as the default engine.
default-storage-engine=InnoDB
default-table-type=InnoDB
And if all of that fails and you can't still find out why or what is happening, then, this might help:
$ sudo service mysqld stop
$ mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.bak
$ mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.bak
$ sudo service mysqld start
It doesn't properly explain why the issue happened but it will help solve it. My next step is verify if the server and application will support a MySQL update to 5.5
I run a daily backup mysqldump backup of the production database (mysql version 5.1.66):
mysqldump --user=username --password=secret -C -e --create-options --hex-blob --net_buffer_length=5000 databasename > file
I also do a daily restore of that database on my development machine (mysql version 5.6.12)
mysql --user=username --password=secret databasename < file
I get the error:
ERROR 1813 (HY000) at line 25: Tablespace for table 'databasename.tablename' exists. Please DISCARD the tablespace before IMPORT.
My reading indicates this is because the mysql innodb database requires the command:
ALTER TABLE tbl_name DISCARD TABLESPACE;
to be run before the table is dropped -- it seems that dropping the table isn't sufficient to get rid of its indexes.
(my development server uses the innodb_file_per_table option)
I don't want to use 'replace' option because i could potentially have data in my development database that was deleted on the production database.
btw after the error the tables are not readable, but restarting mysqld fixes it.
So the question is, is there any mysql dump option that will help fix this issue, or is there another way to import the data that will prevent the error?
thanks in advance for reading.
Sounds like you have a tablename.ibd but no tablename.frm.
To check:
cd to your mysql data directory then the database name.cd /var/lib/mysql/database_name
Search for the table name that is giving the error.
ls tablename.*
You should see two files:
tablename.ibd
tablename.frm
But I'm guessing you don't and only see tablename.ibd
To fix you have a few options:
Add the follow to mysqldump, which will cause the database to be dropped, cleaning up data directory, before restore.--add-drop-database
Copy the tablename.frm from prod over to dev and then issue a delete table statement.
Also:
No need to use net_buffer_length=5000 when you're dumping to a file on localhost.
Other backup solutions - Percona Xtrabackup
I found the easiest way to skip this problem was to manually edit phpmyadmin database dump and edit/change the table that had problems to something else than INNODB. I changed the problem table to ENGINE=MyISAM and voila. Import worked.
CREATE TABLE IF NOT EXISTS `home3_acymailing_tag` (
`tagid` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(250) NOT NULL,
`userid` int(10) unsigned DEFAULT NULL,
PRIMARY KEY (`tagid`),
KEY `useridindex` (`userid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
I also encountered that problem while dropping a schema and creating it again. I overcome this issue by going C:\ProgramData\MySQL\MySQL Server 5.6\data\my_database_name and deleting the tables which remained from the previous database creation. You can also delete the entire database, if you wish.
if you are using XAMPP then first ("stop") MySQL
Then go to C:\xampp\mysql\data\dnb
where in my case dnb is my database name folder.
so then open it and delete .ibd file hence you can only delete it when you already stop MYsql .
then go to phpmyadmin
1 click on phpmyadmin .
2 click on databases that appear below (server.127.0.0.1 in your case my be change)
3 then check your database which you want to drop,and click on drop.
4 then you can create database with same name and import your database successfully .here you can see how you drop database from phpmyadmin
When I run the auto-install script for a new installation of v1.3.3, I get a the following message indicating that none of the tables for the database were installed:
Creating page table... FAILED: Already exists?
I have verified that I provided the correct database credentials and that the database user has create table privileges.
I am running mysql version: Ver 14.14 Distrib 5.5.24, for debian-linux-gnu (x86_64).
Playing around with the mysql create table statements in the setup/install.php script, I discovered the issue. My version of mysql doesn't like the following syntax for declaring the engine type:
TYPE=MyISAM CHARACTER SET utf8 COLLATE utf8_unicode_ci
I replaced TYPE with ENGINE in all the mysql queries in this script and the script was able to create all the database tables.
It appears that in MySQL 5.1, support for the TYPE keyword was finally removed.
This question is based on this thread.
I run unsuccessfully
sudo mysql
\. /users/cs/SO_db/posts.sql
I get the error
ERROR 1146 (42S02): Table 'personal.posts' doesn't exist
MySQL's manual says
A five-character SQLSTATE value
('42S02'). The values are specified by
ANSI SQL and ODBC and are more
standardized. Not all MySQL error
numbers are mapped to SQLSTATE error
codes. The value 'HY000' (general
error) is used for unmapped errors.
and
Error: 1146 SQLSTATE: 42S02
(ER_NO_SUCH_TABLE)
Message: Table '%s.%s' doesn't exist
How can you solve the error message?
The SQL script you have loaded makes reference to a database and/or table which does not exist in the database.
Typically one would not call the mysql tool with sudo, as the system user privileges are different from MySQL users.
To execute an SQL script through mysql I would try something like:
cat somefile.sql | mysql -u <mysqluser> -p <mysqldb>
This command would load 'somefile.sql' into mysql tool, connecting to a MySQL server on localhost as user <mysqluser> and selecting the database <mysqldb>. The mysql tool will prompt for <mysqluser>'s access password before executing the script.
As I mentioned in the post you referenced, you NEED to create the tables first.
Peek at the XML or the SQL output on what columns you need. e.g. here is a table that can hold the output from badges.xml (I don't have the others available right now..)
CREATE TABLE `badges` (
`Id` int(11) NOT NULL default '0',
`UserId` int(11) not NULL,
`Date` datetime not NULL,
`Name` varchar(32) not NULL,
PRIMARY KEY (`Id`),
KEY `Date` (`Date`),
KEY `UserId` (`UserId`)
) ;
Have you actually created the database 'personal' and the table 'posts'?
You might want to try something like:
mysql -h localhost -u <user> -p<password> -D personal < /users/cs/SO_db/posts.sql
Your posts.sql contains some statements referencing a posts table, which doesn't exist in your personal schema.
To "solve" the error, ensure the table is created!
probably your sql file doesn't include the "create table" command.