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.
Related
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...
I have installed mySQL Server and created a user called ej_instance and has set password "password". Logged into server using below command
mysql -u ej_instance -p;
-- entered password
ej_instance has access to only ejabberd database. So I executed command like below
use ejabberd;
Then tried to execute commands like below
SET table_type=InnoDB;
CREATE TABLE users (
username varchar(250) PRIMARY KEY,
password text NOT NULL,
created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) CHARACTER SET utf8;
But it is throwing errors at me. Below are errors
ERROR 1193 (HY000): Unknown system variable 'table_type'
ERROR 1046 (3D000): No database selected
How can get this done? anything else to be changed?
Specify the engine type when creating the table, like this:
USE ejabberd;
CREATE TABLE users (
username varchar(250) PRIMARY KEY,
password text NOT NULL,
created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) CHARACTER SET utf8 ENGINE = INNODB;
If the use error still showing, check:
the database exists
the user ej_instance has privileges to access and create tables on the database
Loggin as root:
#check the database exists
SHOW DATABASES LIKE 'ejabberd';
#check user permissions
SHOW GRANTS FOR 'ej_instance'#'localhost';
SHOW GRANTS FOR 'ej_instance'#'%';
If don't have enough permissions:
#grant all permission on the user for the specified database
GRANT ALL ON ejabberd.* TO 'ej_instance'#'localhost';
GRANT ALL ON ejabberd.* TO 'ej_instance'#'%';
FLUSH PRIVILEGES;
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
I have a recently set up VPS with cPanel.
I've made a user and created a database, and now I would like to import a database onto it.
However, when I try I get the error message
#1044 - Access denied for user 'user'#'localhost' to database 'database'
I suspect that this can be fixed with WHM, but I do not feel like trial and error just yet.
How would I go about fixing this?
When you import a database using phpMyAdmin, normally you do so by importing a text file with a .sql extension. Here is a section of code that may be in a .sql database backup. In your example, the database you are trying to import is named database.
-- phpMyAdmin SQL Dump
-- version 2.11.9.5
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Generation Time: Apr 02, 2010 at 08:01 AM
-- Server version: 5.0.81
-- PHP Version: 5.2.6
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
CREATE DATABASE database;
-- --------------------------------------------------------
--
-- Table structure for table `table`
--
CREATE TABLE IF NOT EXISTS `table` (
`column1` text NOT NULL,
`column2` text NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
When using phpMyAdmin to attempt to import such a file, you will receive an error message similar to:
Error
SQL query:
CREATE DATABASE database;
MySQL said: Documentation
#1044 - Access denied for user 'user'#'localhost' to database 'database'
In this scenario, the cPanel username is user. Because of cPanel's database naming conventions, all database names must begin with the cPanel username followed by _. Using this format you can only creat a database named user_database.
The reason this import failed is because of the following line in the .sql file...
CREATE DATABASE database;
Again, you cannot create a database named database, however you can create a database named user_database.
If you change the line that says: CREATE DATABASE so that it creates: user_database instead of database it will again fail with the following message:
Error
SQL query:
CREATE DATABASE user_database;
MySQL said: Documentation
#1044 - Access denied for user 'user'#'localhost' to database 'user_database'
When using cPanel, databases must be created within the cPanel itself.
Here are the steps to correct thi sissue:
Create the user_database database within cPanel
Comment out the CREATE DATABASE command in my .sql file
To do this, simply change:
CREATE DATABASE database;
to
-- CREATE DATABASE database;
You are simply adding dash-dash-space to the front of the line to comment it out so that it will not be executed.
Log into phpMyAdmin, access the user_database database, and then import as normal.
Before dumping your database, grant full access to your new database user created in Cpanel by the same password of that user:
grant all on database_name.* to database_user#localhost identified by 'password';
Then you need to modify your .sql file (can use notepad++), comment out the part where says create and use the new database:
-- Database: dbname
--
-- CREATE DATABASE IF NOT EXISTS dbname DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
-- USE dbname;
then you should be able to import it to your Cpanel.
To make it official...
The file you're attempting to import probably has something that you don't have permissions for. I would check permissions, then the file you're importing.
Importing UTF8-encoded data into mysql is not working for me. UTF8 characters are corrupted. For example Nöthnagel is displayed as Nöthnagel
I have created a sql dump file to do the importing which contains UTF-8 encoded data. For example:
INSERT INTO `users` VALUES(1, 'Fred','Nöthnagel');
The sequence of bytes representing ö in the file is c3 b6 which I believe is correct, as it displays correctly in vim and in my bash shell which has these environment variables set:
$ env | grep -i utf
LANG=en_US.UTF-8
XTERM_LOCALE=en_US.UTF-8
The mysql db was created as follows:
mysql> CREATE DATABASE mydb CHARACTER SET utf8;
The mysql table was created so:
CREATE TABLE `users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`first_name` varchar(30) NOT NULL,
`last_name` varchar(30) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `last_name` (`last_name`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
I am importing the dump file like so:
mysql -u root -psecret mydb < mydump.sql
Please tell me what is missing from the above.
I think it might have something to do with collation as well, but I'm not sure. In my case it certainly did, since I had to support cyrillic.
Try this, worked for me:
Set initial collation while creating the target database to utf8_unicode_ci
Add SET NAMES 'utf8' COLLATE 'utf8_unicode_ci'; to the top of your sql file
Run mysql -u root -p --default-character-set=utf8 yourDB < yourSQLfile.sql
One more thing, in order to properly get the UTF-8 data form your database, you'll have to modify your connection string as well. For example:
mysql.url=jdbc:mysql://localhost:3306/nbs?useJvmCharsetConverters=false&useDynamicCharsetInfo=false&useUnicode=true&characterEncoding=UTF-8&characterSetResults=UTF-8&useEncoding=true
Additionally, take a look at what my problem was.
Use this command for import utf8 table to database :
mysql -u USERNAME -pPASSWORD --default_character_set utf8 DATABASE < file.sql
The problem was solved by adding this at the top of the sql file:
SET NAMES utf8;
I had a similar problem. There are a number of variables that should be UTF8, not only the database, those include the client, the connection, ther server ...etc.
The solution to your problem is described in this article. The described solution is portable, so it does not only work for utf8, but for all other character sets. You may need to modify it to fit your needs.