Bug #30262 | Backup of Views creates a file containing create table statements of view defs | ||
---|---|---|---|
Submitted: | 7 Aug 2007 1:23 | Modified: | 7 Aug 2007 7:04 |
Reporter: | Craig Everard | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Administrator | Severity: | S3 (Non-critical) |
Version: | 1.2.12 | OS: | Windows (2003 Server R2) |
Assigned to: | CPU Architecture: | Any | |
Tags: | administrator, backups, create, restore, Views |
[7 Aug 2007 1:23]
Craig Everard
[7 Aug 2007 1:28]
Craig Everard
Example of the backup file created
Attachment: SCF P Views.sql (application/octet-stream, text), 61.20 KiB.
[7 Aug 2007 1:29]
Craig Everard
screen shot of backup project
Attachment: mysql-admin-views.JPG (image/jpeg, text), 121.47 KiB.
[7 Aug 2007 4:46]
Valeriy Kravchuk
Thank you for a problem report. Are you really sure that: "I then end up with a view and a table of the same name, where the table didn't exist in the original backed-up schema." Please, check, by restoring your sql file to a new, empty database. Note that you have DROP TABLE v1 before each and every CREATE VIEW v1 in your file.
[7 Aug 2007 5:19]
Craig Everard
OK, I know what has happened here, my apologies. The behaviour must have changed since I upgraded to the latest version of Administrator. In my original test (and all previous backups) I did not have the "Add DROP statements" option checked. Consequently when the backup runs against views, it appears to create a temporary table to build the view against, but doesn't drop in at the end of the script execution. The file I sent you I created after ticking the drop option and so we have DROP statements which would solve my problem. My previous scripts were separated into different files for tables, data and views and carefully ordered so that errors were avoided when building the views. Thanks for your time, by adding the DROP option the problem should be solved.