i have installed Server version: 5.6.25 MySQL Community Server (GPL) on my laptop with OS ubuntu 14.04 lts. Recently i tried to run mysqlimport client program and got errors that i was unable to figure out.
on terminal i type this command and got this error:
mysql> mysqlimport --local test_database employee.txt;
ERROR 1064 (42000): 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 'mysqlimport --local test_database employee.txt' at line 1
Initially, i thought that may be the problem is in the employee.txt file directory which i stored under var/lib/mysql directory.But when i tried this most basic mysqlimport command i again got error!:
mysql> mysqlimport --help;
ERROR 1064 (42000): 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 'mysqlimport --help' at line 1
Thus, i think my current mysql 5.6.25 does not have mysqlimport support.I tried to follow this RPM Package Client Utilities..However that was for linux not ubuntu & all the given Package versions are 5.6.26 not 5.6.25.BTW all of my other configurations such as phpmyadmin & database query works fine.
Therefore, in that situation how should i resolve the problem ?
let me know for further information.
Thanks
Thanks alvits , finally i tried this modified commands from outside the mysql in another terminal:
mysqlimport --local -u root -p test_database home/himadree/mysqlTestingFiles/employee.txt;
it works,BUT the data inside the employee.txt were not correctly restored into the table. my actucal employee.txt contains this tab-dalimated data below:
100 John Doe DBA
200 John Smith Sysadmin
300 Raj Patel Developer
But after mysqlimport command i got this output:
select * from employee;
+-------+-----------------+------+
| empno | ename | job |
+-------+-----------------+------+
| 100 | John Doe | NULL |
| 200 | NULL | NULL |
| 300 | NULL | NULL |
+-------+-----------------+------+
3 rows in set (0.00 sec)
why i m getting some incorrect data on the table?
Yes Finally i realized that there were some extra tabs in the text file & last commands were fine.
Now here is my final table:
mysql> select * from employee;
+-------+------------+-----------+
| empno | ename | job |
+-------+------------+-----------+
| 100 | John Doe | DBA |
| 200 | John Smith | Sysadmin |
| 300 | Raj Patel | Developer |
+-------+------------+-----------+
So, anyone trying to learn the mysqlimport program then be careful:
whether the input text file properly delimited or not.
use mysqlimport program outside from mysql program itself with opening another terminal/shell on your OS etc.
Thanks a lot.
In Ubuntu, shell, I ditched mysqlimport and instead use:
MYSQL -h blah < file.sql
Related
I had set --secure-file-priv as following:
mysql> show variables like '%secure%';
+--------------------------+----------+
| Variable_name | Value |
+--------------------------+----------+
| require_secure_transport | OFF |
| secure_auth | ON |
| secure_file_priv | E:\test\ |
+--------------------------+----------+
but I got an error like this:
D:\Tool\mysql-5.7.17-win32\bin>mysqlimport -u root -p my_test tb < e:test/new/outfile.sql
Enter password:
mysqlimport: Error: 1290, The MySQL server is running with the --secure-file-priv option so it cannot execute this statement, when using table: tb
Another error:
D:\Tool\mysql-5.7.17-win32\bin>mysqlimport -u root -p my_test tb < e:test\new\outfile.sql
Enter password:
mysqlimport: Error: 1290, The MySQL server is running with the --secure-file-priv option so it cannot execute this statement, when using table: tb
what should I do to tackle this?
The fact is that in my.ini you did not specify the correct directory
Secure File Priv.
secure-file-priv="F:/directory"
So i created a database in MySQL Workbench and I am trying to view them on the MySQL Command Line Client because i want to do my queries there instead of the workbench.
Here's whats happening:
mysql> use policestation(crime);
Database changed
mysql> show tables;
+--------------------------------+
| Tables_in_policestation(crime) |
+--------------------------------+
| accused |
| case |
| complainant |
| investigation_officer |
| outcome |
| section_of_law |
+--------------------------------+
6 rows in set (0.04 sec)
mysql> select * from case;
ERROR 1064 (42000): 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 'case' at line 1
The same query works fine in MySQL Workbech. Also it works for all other tables in Command Line Client.
It's b/c Case is a MySQL reserved keyword: https://dev.mysql.com/doc/refman/5.5/en/keywords.html
You'll need to seround reserved keywords with tick marks not quotes.
Example:
SELECT * FROM `case`
Not the same as
SELECT * FROM 'case'
Also here is another helpful link:
Syntax error due to using a reserved word as a table or column name in MySQL
I am new to MySQL and in the learning curve ,
I wanted somehelp ..
I tried importing the temp database from https://github.com/datacharmer/test_db ... I am having diffulties in importing the same .
I think I have wrongly imported and I wanted to drop the table , But its not allowing me .
I get the below error .
mysql> show databases;
+-------------------------+
| Database |
+-------------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| #mysql50#test_db-master |
+-------------------------+
5 rows in set (0.00 sec)
I am not getting any response in Terminal , but when I tried in MySQL Workbench , I am getting the below error
*drop '#mysql50#test_db-master'
22:04:30 drop '#mysql50#test_db-master' Error Code: 1064. 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 ''#mysql50#test_db-master'' at line 1 0.00034 sec*
I wanted to delete this table & wanted to create a new one again ...
https://dev.mysql.com/doc/refman/5.7/en/drop-database.html shows the syntax for DROP DATABASE.
Pro tip: Read documentation. You can get answers more quickly than by posting on Stack Overflow.
I set two user-defined variables as shown below but after some time, I forgot the names:
SET #a = 2, #b = 3;
So, does MySQL have the command that displays all user-defined variables?
Starting with MySQL 5.7, the performance schema exposes user variables.
See table performance_schema.user_variables_by_thread
https://dev.mysql.com/doc/refman/5.7/en/performance-schema-user-variable-tables.html
If you have MariaDB (a binary "drop-in" equivalent of MySQL) there is a plugin available, provided by MariaDB itself.
MariaDB 10.2 (equivalent to MySQL 5.7) and above has a plugin that creates a "USER_VARIABLES" table.
Here is how to install the plugin.
Here is an example of its use:
SELECT * FROM information_schema.USER_VARIABLES ORDER BY VARIABLE_NAME;
+---------------+----------------+---------------+--------------------+
| VARIABLE_NAME | VARIABLE_VALUE | VARIABLE_TYPE | CHARACTER_SET_NAME |
+---------------+----------------+---------------+--------------------+
| var | 0 | INT | utf8 |
| var2 | abc | VARCHAR | utf8 |
+---------------+----------------+---------------+--------------------+
MariaDB installs the plugin by default after version MariaDB 10.2.6.
The link above shows how to install it for prior versions.
Double check what version of "mysql" you're running, because sometimes people will refer to a MariaDB as MySQL, due to its use as a "binary drop in replacement" for MySQL. So it's possible that you are running a MariaDB database.
I am not aware of MySQL providing anything similar.
How to check which version of mysql you're running (the prompt is in bold)
From the command line:
$ mysql -v
From the mysql command client:
mysql> SHOW VARIABLES LIKE "%version%";
It is also shown when you first log into the mysql command client, which you can do via:
$ mysql -u your_mysql_username --password=your_mysql_password
With performance_schema.user_variables_by_thread, you can show all user-defined variables as shown below:
mysql> SELECT * FROM performance_schema.user_variables_by_thread;
+-----------+---------------+--------------------------------+
| THREAD_ID | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+---------------+--------------------------------+
| 69 | first_name | 0x4A6F686E |
| 69 | last_name | 0x536D697468 |
+-----------+---------------+--------------------------------+
I have run mysql -u root -p gf < ~/gf_backup.sql to restore my db. However when I see the process list I see that one query has has been idle for a long time. I do not know the reason why.
mysql> show processlist;
+-----+------+-----------+-------------+---------+-------+-----------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+-----------+-------------+---------+-------+-----------+------------------------------------------------------------------------------------------------------+
| 662 | root | localhost | gf | Query | 18925 | query end | INSERT INTO `gf_1` VALUES (1767654,'90026','Lddd',3343,34349),(1 |
| 672 | root | localhost | gf | Query | 0 | NULL | show processlist |
+-----+------+-----------+-------------+---------+-------+-----------+------------------------------------------------------------------------------------------------------+
Please check free space with df -h command (if under Linux/Unix) if you're out of space do not kill or restart MySQL until it catch up with changes when you free some space.
you may also want to check max_allowed_packet setting in my.cnf and set it to something like 256M, please refer to http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_max_allowed_packet
Probably your dump is very large and contains much normalized data (records split into a bunch of tables, with a bunch of foreign key constraints, indexes and so on).
If so, you may try to remove all constraints and index definitions from the SQL file, then import the data and re-create the former removed directives. This is a well-known trick to speed up imports, because INSERT commands without validation of any constraints are a lot faster, and creation of an index and so on afterwards can be done in a single transaction.
See also: http://support.tigertech.net/mysql-large-inserts
Of course, you should kill the query first. And remove all fragments it created already.