Help - Search - Members - Calendar
Full Version: Restoring A Mysql Dump
Movable Type Community Forum > Installing and Upgrading > Databases
NicoGrrl
I've followed the directions for Backing Up Via phpMyAdmin in the MT 3.2 documentation.

So far so good.

But the instructions for restoring (at that same link) don't quite correspond to what I am seeing on my server, which is running phpMyAdmin 2.6.4-pl3. The interface is a bit different.

The instructions for restoring say:
QUOTE
Click on the SQL tab in the top menu bar. You will see a button labelled "Choose file". Click it and select the MySQL export file from your computer in the resulting dialog box. Leave the "Compression" option at "Autodetect" unless you experience problems. Click on Go and your database will be restored!

I am able to find a page where I can choose a file for importing. But when I do that, and click the Go button, I get a MySQL error:

#1007 - Can't create database 'DatabaseName; database exists

Am I correct in assuming that the restore process allows importing to an existing database, and not only the recreation of a database that no longer exists?

Fortunately this is not a critical issue at the moment -- I'm just testing things to make sure I understand how things work.

But if someone can point me in the right direction on this, I'd appreciate it.

Thank you!
lisa
There are a couple of ways to back up your database.

1) If you click on Export on the front page of phpMyAdmin, it will back up everything, including the database. If you select "Database export options: Add DROP DATABASE" then it will remove the database before importing from your file. If you prefer not to do that, then keep reading.

2) If you click on your database name (in the left column) and then click on Export, you'll see a list of your tables instead of your database name. You can then select the tables you want to backup and this time when you restore, it will only try to create the tables for you, not the database. Under "Structure", you can select "Add DROP TABLE" so that it will drop your tables and reimport them for you.

I hope that helped.
NicoGrrl
Thank you, Lisa. What you describe makes sense.

When I tried your first method, I got an error that DROP DATABASE statements were disabled. Do you know if that's controlled by my host, or do I have access to that setting. A quick look around the php admin pages didn't reveal that setting. (I'm new to both php and MySQL, and to how these resources are managed by my host, so I'd rather not manually delete the db itself.)

But your second method worked like a charm! smile.gif Thank you!

The restore took quite a while, even for a small db with only about 30 short entries. So I guess patience is in order when doing this.

A question: Am I correct that the second method, when ALL the tables are exported, is functionally the same as the first method, with the exception that the structure of the backup file doesn't include the database "container" itself?

FYI, what got me interested in this method of backup and restore is that I would like to use Arvind's CustomFields plugin, and MT's Export/Import functions don't see those fields. But they are of course included in a MySQL dump. Given that, am I correct that if I combine MT's internal Import/Export functions, with a MySQL export and restore of the particular table that holds the CustomFields data ('mt_plugindata'), then the data would sync up correctly providing the MT export file and the MySQL backup were taken from the same data set? (Did that make sense?)

Thanks again for your help!
lisa
QUOTE (NicoGrrl @ Feb 7 2006, 06:20 PM)
When I tried your first method, I got an error that DROP DATABASE statements were disabled. Do you know if that's controlled by my host, or do I have access to that setting. A quick look around the php admin pages didn't reveal that setting. (I'm new to both php and MySQL, and to how these resources are managed by my host, so I'd rather not manually delete the db itself.) 


Strange. I'm not sure but I haven't had a host where I've had that disabled. It may be that your database user doesn't have drop permissions?

QUOTE
But your second method worked like a charm! smile.gif Thank you!


You're welcome. smile.gif

QUOTE
A question: Am I correct that the second method, when ALL the tables are exported, is functionally the same as the first method, with the exception that the structure of the backup file doesn't include the database "container" itself?


Yes, that's correct. It's actually better to use the second method in case you move to a new web hosting account (a lot of hosts use username_dbname as their naming scheme so if you picked a different username at the new host, the database name wouldn't match/work anyway). I always backup my tables, not the database personally. smile.gif

QUOTE
FYI, what got me interested in this method of backup and restore is that I would like to use Arvind's CustomFields plugin, and MT's Export/Import functions don't see those fields. But they are of course included in a MySQL dump. Given that, am I correct that if I combine MT's internal Import/Export functions, with a MySQL export and restore of the particular table that holds the CustomFields data ('mt_plugindata'), then the data would sync up correctly providing the MT export file and the MySQL backup were taken from the same data set? (Did that make sense?) 


That seems reasonable but hopefully Arvind will notice his name and stop by to comment on this. huh.gif

Lisa
NicoGrrl
QUOTE (lisa @ Feb 8 2006, 04:26 PM)
QUOTE
A question: Am I correct that the second method, when ALL the tables are exported, is functionally the same as the first method, with the exception that the structure of the backup file doesn't include the database "container" itself?


Yes, that's correct. It's actually better to use the second method in case you move to a new web hosting account (a lot of hosts use username_dbname as their naming scheme so if you picked a different username at the new host, the database name wouldn't match/work anyway). I always backup my tables, not the database personally. smile.gif


Thanks Lisa! Sounds like the way to go!
Torne
Hi, I have trouble transferring my database. I have an account in a freehost, but I transferred to another host because of their services. But when I try to import my database, I always get this message-

Error at the line 12: CREATE DATABASE `oldtorne_db1` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;

Query: CREATE DATABASE `oldtorne_db1` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;

MySQL: Access denied for user 'torne_db1'@'localhost' to database 'oldtorne_db1'.


"torne_db1" is my new, empty database and I want all of the tables "oldtorne_db1" to be transferred/copied to "torne_db1".

Thanks in advance.
OtherNiceMan
Does the user torne_db1 exist in mySQL and does it have the correct permissions to create databases?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.