mysqlimport - where is the imported data stored? - mysql

Huge mysql noob. Sorry in advance if this is dumb but I have searched around before posting.
I use mysqlimport on a local file to a mysql database that's running on my computer. If I delete the original file that was imported, can I still access the data? If so, where is the data being stored? On some Oracle server?
If it's stored locally, is it stored in a compressed version that takes up less space on my harddrive?
Thanks,
fertileneutrino

if you import a file to a database, it is going to store an instance of that data in the database, so yes, you should still be able to access the data, but why would you want to delete it?
It is being stored in a pool of database files in mySQL, they are referenced when you start mysql...yes the imported doc, is just a .dat file in most cases, as your database file.

When you import the data it is stored in database files on your local machine, using the mysql client program or something like phpmyadmin you should be able to view your imported data.
It's no longer stored in the same format as it was when you first imported it.
you can use something like mysqldump to get the data back out.
http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html

Related

secure_file_priv= NULL in mySQL workbench MAC

I am new to mySql workbench and need help importing a large file for analysis. I read here
MySQL workbench table data import wizard extremely slow that the data import wizard shouldn't be used so i used LOAD DATA INFILE as suggested but I had issues importing due to secure_file_priv=NULL.
I found a solution here How should I tackle --secure-file-priv in MySQL? but I don't know how to reset the value of secure_file_priv.
I found some sources that use command line to do so but I don't know how to use mySql workbench from command line.
Any help on how to disable this or change it would be appreciated
don't touch it, it is basicakky a security feature.
use the data import under server in workbench,
If you want do it by sql, ecery thng os written already in How should I tackle --secure-file-priv in MySQL? which you linked
simple
copy your file in the folder, that you get as value, when you do a SHOW VARIABLES LIKE "secure_file_priv";
Now you can make a LOAD DAT ideally from the console, because then you have no timeout.
Read also Bulk insert in the namual so that you can optimize a big data import
If you really want to use any folder which is not recommended, you have to edit the my.ini file for that and restart to server (both can be done in Workbench as well, you see in the picture options file and Start/shutdown.) There are some other ways do restart the service.
Here are the basics good described of importing csv

How to create and edit database file .db from mySql?

I just want to know if we can create a database .db file from MySQL. If so, how to create .db file? I already knew that, .db file can be created from SQLite and then this .db file can be edited by Qt application.
If we can create .db database from MySQL, can we load and further edit or add data from Qt application?
MySQL needs dozens of files to represent the database plus a server process to interface with those files. There is no such thing as a ".db file" that it can create. The best you can do is a .sql dump that's in the MySQL dialect, but this is pretty much useless without a MySQL server to restore it to.
SQLite is designed as a light-weight library that can interface with a single file that is self-contained. It's expressly made for the purpose you're describing.
If you want to convert from SQLite to MySQL that's possible, but it's not always trivial.

convert mysql to sqlite3

I need suggestions on how to create a SQLite database from an old MySQL database using Windows 7. I have MySQL's .FRM and .IDB files, and a SQL File (which I believe to be a dump, not a script, unfortunately). I tried to just use sqlite's .read and got a bunch of syntax errors about lock and unlock, which is why I'm guessing it's a dump file. This is a 30 gig database, so recreating by hand isn't really an option.
Is there any way for me to do something like export to a CSV, then import it into SQLite? I tried to use mysql2sqlite with Cygwin to convert it, and got a ./mysql2sqlite.sh: line 2: $'\r': command not found.
Any ideas?
There is a collection of tools in the official SQLite website.
Wiki Link

Imported data are missing in Mysql

I had copyed the data folder under wamp/bin/mysql/mysql(v)/data befor formate my computer, then after installing new os and then wamp I replace the data folder.
Now when I opening phpmyadmin the list of databases are showing but under the data base the tables are not shownig.
When I am using the myadminer it shows the lisst of table but not the tables data.
when I am using sqlbuddy one warning is showing in the place of listing tables. warning is like
Warning: array_key_exists() expects parameter 2 to be array, boolean given in E:\wamp\apps\sqlbuddy1.3.3\dboverview.php on line 215
you should have taken a proper backups - using mysqldump. if you used innodb storage engin and it was configured to keep log files or tablespace files somewhere else - i'm afraid you've lost your data.
I'm sorry, you have lost your data. In the future create backups frequently and create MySQL dump whenever you want to migrate your database.

MySQL 5.0.22 export dump file not importing - syntax errors

I backed up my db with mysqldump from phpMyAdmin. Using MySQL 5.0.22. Made no changes to database file. Import fails. Found many instances of extra spaces using notepad, but now cannot find any other such extraneous spaces. Error is 1064.
Any suggestions on how to import file properly?
Thanks.
I encountered problems with mysql dumps of entire databases including views. So now I dump the tables and data as a separate dump, and export the views, stored routines and functions separately. I restore the tables first then the views etc.
Having come from MS SQL Server and Oracle I would like to know if there are any totally reliable tools out there for MySQL database backups and restores.
You have done several things wrong here
Using PHPMyAdmin for anything critical, especially backups. It is not production-ready, in my experience. Feel free to use it for unimportant read-only work on noncritical servers however.
Editing mysqldump files with notepad (or any other editor). Despite appearances, mysql dump files are not text files and should not be edited with any editor. They contain binary data which is not valid in most character encodings, and therefore can probably not be loaded/saved without introducing errors.
Make a fresh dump using mysqldump, which is the only reliable way of making them, and import that. Do not edit mysql dump files using notepad or any other text tool (this includes the likes of grep, sed etc).
If you need to edit a mysql dump file, then restore it into another (i.e. non-production) database instance, make the necessary changes using SQL commands and re-dump the database. This may be slow but it's reliable.