I am trying to export just the rows of a mysql table without the table information to an xml file. I read that the mysqldump command will get the job done but I cant manage to get the correct syntax. Can someone post an example code for mysqldump command? Thank you.
$command="mysqldump --xml ";
Try the script on this page: http://www.chriswashington.net/tutorials/export-mysql-database-table-data-to-xml-file
By any chance you are not trying to run that command inside mysql_query are you ? It wont work that way. mysqldump is a command line utility.
To run it from php you would need to use the system() function, documentation - http://php.net/manual/en/function.system.php
If you are on a shared host with PHP in safe mode, or the system function is explicitly disabled in php.ini, then you will not be able to do this.
In that case you would need to read the data from your table using a SELECT query and iterating on all rows and potting it into an XML file, using XMLWriter or DOMDocument
Related
I'm trying run exec with mysqldump in my PHP file. It doesn't work, I'm even trying to use it without variables like this:
exec('mysqldump --user=xx --password=xx --host=xx db settings > /output/dump5.sql');
It creates empty file.
But when I run this command in ssh, it works. Why?
Do you need to do this from php script ?
I assume that you want to do the backup frequently, so maybe adding it to cron job will better solution.
Scenario:
I have built a PHP framework that uses a postgresql database. The framework comes shipped with a .sql file which is a dump of the default tables and data that the framework requires.
I want to be able to run the sql file from the client (PHP), rather than the command line, in order to import the data. This is because I have come across some server setups where accessing the command line is not always a possibility, and/or running certain commands isn't possible (pg_restore may not be accessible to the PHP user for example).
I have tried simply splitting up the .sql file and running it as a query using the pg_sql PHP extension, however because the dump file uses COPY commands to create the data, this doesn't seem to work. It seems to be that because COPY is used, the .sql file expects to be imported using the pg_restore command (unless I am missing something?).
Question:
So the question is, how can I restore the .sql dump, or create the .sql dump in a way that it can be restored via the client (PHP) rather than the command line?
For example:
<?php pg_query(file_get_contents($sqlFile)); ?>
Rather than:
$ pg_restore -d dbname filename
Example of the error:
I am using pgAdmin III to generate the .sql dump, using the "plain" setting. In the .sql file, the data that will be inserted into a table looks like this:
COPY core_classes_models_api (id, label, class, namespace, description, "extensionName", "readAccess") FROM stdin;
1 data Data \\Core\\Components\\Apis\\Data The data api Core 310
\.
If I then run the above sql within a pgAdmin III query window, I get the following error:
ERROR: syntax error at or near "1"
LINE 708: 1 data Data \\Core\\Components\\Apis\\Data The data api Core...
This was a bit tricky to find, but after some investigation, it appears that pg_dump's "plain" format (which generates a plain-text SQL file) generates COPY commands rather than INSERT commands by default.
Looking at the specification for the pg_dump here, I found the option for --inserts. Configuring this option will allow the dump to create INSERT commands where it would normally create COPY commands.
The specification does state:
This will make restoration very slow; it is mainly useful for making dumps that can be loaded into non-PostgreSQL databases. However, since this option generates a separate command for each row, an error in reloading a row causes only that row to be lost rather than the entire table contents.
This works for my purposes however, and hopefully will help others with the same problem!
I want to be able to dump a whole sqlite database to a file (database.sql) so as to use it as a backup. The problem is that exec() in PHP doesn't seem to run correctly the ".dump" command as it gives only "COMMIT;" as a result and not the whole text:
$db = new SQLite3('checks_db.db');
$results=$db->exec('.dump');
$content=$results->fetchArray();
If I run it from sqlite3 it gives both the schema and the insert insrtuctions with the data.
Perhaps I should also mention that the database has 777 permissions.
Can anyone write an example of the syntax of the '.dump' command in php-sqlite3?
The SQLite database does not have a .dump command.
The sqlite3 command-line shell has a .dump command.
To be able to use it, you would have to execute that tool; something like this:
exec('sqlite3 /some/where/checks_db.db .dump', $output);
The easiest way to make a backup would be to copy the database file itself, but using the shell's .backup command would be safer.
I have a 28 MB sql file need to import to mysql.
Firstly, i'm using xampp to import, and it fails, and so i change my max_file_uploads, post_size(something like that)in php.ini-development and php.ini-product to 40 MB, but it still show "max:2048kb" and import fail again.
From research, i've learned to import by using mysql.exe, so i open mysql.exe and type the command line(msdos) below:
-u root -p dbname < C:\xxx\xxx\sqlfile.sql
but still failed again and again.....
what the problem is? xampp? or my sql setting?
Try this:
mysql -uroot -p --max_allowed_packet=24M dbname
Once you log into the database:
source C:\xxx\xxx\sqlfile.sql
I think that you should be able to load your file
How large is your file?. You might as well do it from a console:
mysql -u##USER## -p ##YOUR_DATABASE## < ##PATH_TO_YOUR_FILE##
Do that without executing your mysql.ext file: just "cd" right into the directory and try the command.
It will ask for your password and start importing right away. Don't forget to create the database or delete all tables if it's already there.
I always found this approach quick, painless and easier that rolling around with php directives, phpmyadmin configuration or external applications. It's right there, built into the mysql core.
You should increase max_allowed_packet in MySQL.
Just execute this command before importing your file:
set global max_allowed_packet=1000000000;
I also fetched the similar problem. So after that I also conclude , large sql file will never be imported to mysql. It will always give timeout error.
Then I found a solution.
There is an software Heidisql.
follow below steps:-
1) download the software.
2) then install the software
3) create new session in Heidisql and open the session
4) then go to Tools -> Load SQL File -> Browse.
That's it. This solution works best for me.
check the link here
I found the only solution was to log in to MySQL from the command line and use the 'source' command:-
1) cd to the directory containing your SQL file for import, then log into MySQL:
#> mysql -u YOURUSERNAME -p -h localhost
2) use MySQL commands to import the data:
#> use NAMEOFYOURDB;
#> source NAMEOFFILETOIMPORT.sql
This also feeds back info about progress to your terminal, which is reassuring.
I am attempting to dumping a Microsoft SQL (MSSQL) database to a file similar to how i would dump from a MySQL database using php:
$cmd = "mysql --user=".$db_user." --password=".$db_password." --host=".$hostname." --database=".$database." --execute='SELECT * FROM ".$database." '> file.txt";
exec($cmd);
But i am trying to figure out the similarities in the command line as to how it is done above with MySQL
What is the proper command line syntax to execute this?
Thanks.
First, you need to write and test your BACKUP command in TSQL. Second, you need to execute it, either using sqlcmd.exe (Windows only) or by connecting directly to the database with whatever MSSQL drivers you use in PHP.
Since the SQL Server documentation is very complete and has numerous examples, you should be able to write the commands yourself. If you still have problems, please post what you have tried so far and exactly what you can't figure out.
Finally, you should always mention the version and edition of SQL Server, because it's often important to know when answering questions.