If You export a view with 2.11.5 and you wish to import it in the same Database at a other machine, the creation of the placeholder table fails, because they exists in an older version, also if you have choosen drop table at the export.
The IF NOT EXISTS Option is not the solution, because it leaves the old tables in their state.
I try to explain a little szenario:
We have a developer and a production machine. The tables and views are the following:
CREATE TABLE test ( value INT );
CREATE VIEW testview AS SELECT * FROM test;
If You export with the default IF NOT EXISTS in an empty Database with the same name,
all works fine. By the way, if the target DB has a other name the fully qualified names in the dump are a problem.
After that you make some changes at your developer machine at the table structure:
ALTER TABLE test ADD secondvalue INT;
The next export is without IF NOT EXISTS, because You wish to propagate the structural changes.
We select DROP TABLE / DROP VIEW to kill the old structure. A Reimport to the not empty database
produce the error Table testview already exists, because the view is DROPPED to late directly before
the creating of the new VIEW.
I hope that makes it much clearer.
Falk
PS: Should I start a new Bug for the fully qualified Views, they prevent an import to a other database at the same machine.
Perhaps you have to add a switch for full qualified export
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A solution proposal for the problem is to include in sql.php in the
function PMA_getTableDefStandIn( $db, $view, $crlf)
to change the first lines in the following way:
$create_query = '';
if ( !empty($GLOBALS['sql_drop_table'])) {
$create_query .= 'DROP VIEW IF EXISTS ' .PMA_backquote($view) . ';' . $crlf;
}
$create_query .= 'CREATE TABLE ';
that works fine for me, but it isn't tested for other scenarios. Sorry for this way to transmit code, but I didn't involved in the development proccess and I'm afraid to have not enough time to be a serious, reliable and useful developer in the community.
PS: I start also the new BUG for the full qualified names
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=210714
Originator: NO
I think you did not click the option "Add IF NOT EXISTS" when exporting.
Logged In: YES
user_id=596866
Originator: YES
The IF NOT EXISTS Option is not the solution, because it leaves the old tables in their state.
I try to explain a little szenario:
We have a developer and a production machine. The tables and views are the following:
CREATE TABLE test ( value INT );
CREATE VIEW testview AS SELECT * FROM test;
If You export with the default IF NOT EXISTS in an empty Database with the same name,
all works fine. By the way, if the target DB has a other name the fully qualified names in the dump are a problem.
After that you make some changes at your developer machine at the table structure:
ALTER TABLE test ADD secondvalue INT;
The next export is without IF NOT EXISTS, because You wish to propagate the structural changes.
We select DROP TABLE / DROP VIEW to kill the old structure. A Reimport to the not empty database
produce the error Table testview already exists, because the view is DROPPED to late directly before
the creating of the new VIEW.
I hope that makes it much clearer.
Falk
PS: Should I start a new Bug for the fully qualified Views, they prevent an import to a other database at the same machine.
Perhaps you have to add a switch for full qualified export
Logged In: YES
user_id=210714
Originator: NO
Yes, please start a new bug entry for the other bug.
Logged In: YES
user_id=596866
Originator: YES
A solution proposal for the problem is to include in sql.php in the
function PMA_getTableDefStandIn( $db, $view, $crlf)
to change the first lines in the following way:
$create_query = '';
if ( !empty($GLOBALS['sql_drop_table'])) {
$create_query .= 'DROP VIEW IF EXISTS ' .PMA_backquote($view) . ';' . $crlf;
}
$create_query .= 'CREATE TABLE ';
that works fine for me, but it isn't tested for other scenarios. Sorry for this way to transmit code, but I didn't involved in the development proccess and I'm afraid to have not enough time to be a serious, reliable and useful developer in the community.
PS: I start also the new BUG for the full qualified names
Logged In: YES
user_id=210714
Originator: NO
Thanks for the solution, I merged it with some changes:
http://phpmyadmin.svn.sourceforge.net/viewvc/phpmyadmin/branches/QA_2_11/phpMyAdmin/libraries/export/sql.php?r1=11160&r2=11169
and thanks for the complete test case, very useful!