I am using windows terminal to create a simple database. I was wondering is the code used saved anywhere or do I have to save it? And how? I need to save the code I used for creating the database that's why I'm asking.
If you are talking about SQL Server, you can script out the database you created - just right click on the database in Management Studio, and script away!
Yes, you should save your work. Most tools don't save your indentation, they often format the sql in their own way - sometimees as
CREATE TABLE user#host.dbname.table AS ...
so it works to reconstruct your database, but isn't well readable. The worst thing I ever saw was what MsAccess did to my Input in the SQL-Window (but it was 15 years ago).
In MySQL you can use SHOW CREATE TABLE xxx to see the definition for your table(s).
Using mysqldump can help you create an sql file which you can later run to create a DB identical to yours.
It has many useful options you can read about here.
For your case it seems you need the schema only, without the data - see a how-to here. Basically all you need is the command:
mysqldump --no-data -u Username -pPassword mydatabase
Related
I have a database and have saved the code on a separate document for a number of queries - is there anyway of saving them as part of the database as some kind of list so that they can be clicked on to run them rather than keeping on having to paste the code in?
I realise that there are various Reports systems available to purchase on line, but this is a small database and a one-off, and they look complicated and not worth the trouble.
Is there anyway of streamlining this?
If I understand correctly you can write those sql queries to a script-or bunch of script files- file and directly run on mysql without copy/paste.
mysql -u user -ppass < script.sql
I've exported a database via SSH and I didn't add --routine command to export the routines.
Now I don't have any access to this database, and I have only one .sql file. is there any way to restore and find the routines through PHP code or database structures?
No, sorry, in this case I think you're out of luck. Looking at the database structure, you won't be able to figure out what a routine might have done. Likewise, looking at the PHP code is probably not going to help. If you know what the routines did (for instance, manipulate data on insert, maintenance by deleting some rows, or some such) you can work through recreating it, but that's basically reverse engineering it based on what breaks when you try to run your application.
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:
Search and replace all references to some_user#localhost in your dump file with your new user (the one you use to import the dump, e.g. root#localhost)
Or you can grant *some_user* appropriate rights on the new database so that views can be created under his account
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.
What I found to solve the problem is to use the 'sql security invoker' when creating the view initially.
create or replace sql security invoker view <VIEW_NAME> as select ...
It defines access to the view by the invoker, and not the definer.
Then when the dump file is loaded, the view is create correctly.
With Amazon RDS:
To make this work with Amazon RDS, which does not allow super priv (which is needed to do the above) one can run this command to on the dump file:
# Remove DEFINER statement from VIEWS in Dump file
sed -i 's/\sDEFINER=`[^`]*`#`[^`]*`//' $DUMPFILE_NAME
Then when the dump file is loaded into an RDS, the view is create correctly.
I found the problem in my case. I'm unsure that it solves similar reports on the web.
This was fundamentally a permission problem that resulted from trying to copy this database to a new name. Permissions didn't exist for this user and schema (locus on curation2). I manually added 'GRANT ALL ON curation2.* TO locus' (locus is the user reported in the error). After doing this, the above command line worked fine.
The lesson is that one must manually grant necessary permissions to the destination database and tables when creating a new database.
Couple of things:
1.) Yes, you can create the views using some client BUT perhaps the owner of the tables is not the owner of the view, which leads to
2.) Usually, doing backups of views in mysql includes some "useless garbage" like
create algorithm xxx definer=<USER> sql security view <view_name> as ....
and that user often includes the IP or machine name the user logged on when creating the view... SO, the view won't create properly. Check that out, might help you.
I'm using Mysql workbench to develop my database for my application.
I use at least two databases,for example:
my_local : my local testing database that it's always synchronized with mysql workbench
myserver_database : the final database in the server,keep in mind that this database is in production and users WILL update it and i can't loose any information stored into it.
Now i can synchronyze my database every time i want but i can't find a way to update the scheme to the final server because they have different names,i get something like:
my_local => N/A
N/A <= myserver_database
in the past i simply renamed the database in mysql workbench but it doesen't seem to work anymore,probably because of a bug.
I want to be able to synchronize the same workbench scheme with different databases,regardless of the database name,i didn't find a way to force the database name even by modifying the default_scheme.
Please keep in mind i'll do it a lot of times so it's better to avoid triky or dangerous solutions if possible.
I know this question is quite old but I was able to do this on workbench 5.2.40 and there are not many updated resources online explaining how.
First I got a script of my old database:
mysqldump -no-data myolddb > script.sql
(I only want to synch the schemas, this can be done on the workbench too)
now the trick is to modify the script by adding use mynewdb; as its first line, this way the workbench won't say N/A or default schema nonsense.
On the workbench I created a EER model of mynewdb which is on my server, and then "Database->Synchronize with any source" and select from "model Schemadata" to "Script file" in the wizard using the script I modified initially. And then the Synch wizard worked like it should.
When I use the phpMyAdmin export, it has an option for MS SQL export compatibility. However, the resulting file includes many non-MS SQL compatible items, such as mediumtext and enum datatypes. How do I work around this issue?
mysqldump --compatible=mssql -uroot -p some_database > output_file_mssql.sql
vs
mysqldump -uroot -p some_database > output_file.sql
Looking at the difference between the two files will show you some things to check out.
I hope that helps some.
If you are unable to locate a way for phpMyAdmin to generate an exported file of the correct format, then you'll have to edit the resulting exported file to make it compatible with MS SQL. You may need to use regular expressions to, for example, replace ENUM datatypes.
If you find that you have to export data frequently, you may find that writing a short text processing script that you can re-run as needed will save you time.
Oh, and take care that your text editor or favorite scripting language can properly handle the character encoding of the file generated by phpMyAdmin.
This documentation seems pretty conclusive - http://www.waynezim.com/2010/03/how-to-export-mysql-database-to-mssql-using-phpmyadmin/