Environment: Ubuntu 11.10, MySQL 5.1.58
I have a small database with views. When I try to dump and restore, I get
ERROR 1356 (HY000) at line 1693: View 'curation2.condition_reference_qrm_v' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
However, I can connect to the partially-restored database and create the view myself. Therefore, I suspect that the error message results from an issue unrelated to the view itself (but rather how it's restored, perhaps).
Here's the simple approach I use to demonstrate the problem:
MYSQL_PWD='xxx' mysqldump -u root --routines -B curation \
| perl -pe 's/`curation`/`curation2`/' \
| MYSQL_PWD='xxx' mysql -u root
There are many other reports online of similar problems. The mysqldump man page has a cryptic note about bugs with backing up views, but it's written as a historical problem rather than a current one.
So, the question is: Can MySQL reliably restore backups that contain views or not? If it can, how? If not, what do people do as a workaround?
Thanks, Reece
This question is a bit old, but I've just wasted a couple of hours trying to solve the exactly same issue, so I guess a clear explanation could come in handy to someone in the future...
To cut to the chase: The problem is in the DEFINER field in your mysql dump. It looks something like:
/*!50013 DEFINER=`some_user`@`localhost` SQL SECURITY DEFINER */
The problem is that this *some_user@localhost* will always be hardcoded to the user account that was used to create the view in the original DB and NOT the user that you've used to export or import the database as one would expect (or at least I did). And later, during the import, this user will be used to re-create the view.
So you can export/import as root, but if the original DB is running under another user and it has no CREATE VIEW rights in the new database, the import will fail.
You have two simple solutions:
some_user
@localhost
in your dump file with your new user (the one you use to import the dump, e.g. root@localhost)Either way will fix the problem, but I think the first approach is way better and cleaner, as you don't have to worry about multiple users in the future.