I've been trying to work out the best way of copying structure & data from one database to another but the PHPMyAdmin export seems to churn out pretty poor scripts. The most obvious example is if I export a database (structure & data) then try and re-import on the same server (using the drop tables function to prevent clashes), I get a syntax error!? I would have thought PHPMyAdmin would be able to parse its own exports.
The error I get is:
Error SQL query:
$$
DROP PROCEDURE IF EXISTS `CMS_identifyFileType`$$
MySQL said: Documentation
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '$
DROP PROCEDURE IF EXISTS `CMS_identifyFileType`' at line 1
It looks odd to me that the script has weird apostrophes?
Does anyone have any tips on what I might be doing wrong? I have to manually add the 'use myDatabasename;' to the script to get it to work, not sure if I'm missing some other stuff.
My MySQL version is 5.1.73-community running on a Windows Server 2008 R2 server.
Thanks
Bob
I suspect you've amended the output file.
For table and index definitions, mysqladmin uses the default delimiter ';' but for procedures and functions it uses '$$'. The DBMS needs to know that the delimiter has changed - hence in the export file there should be a line like this between a table definition and a procedure definition:
DELIMITER $$
BTW the weird apostrophes around (for example) CMS_identifyFileType are to be expected in MySQL - see Using backticks around field names for a discussion.
I have no idea if this is the correct way to do it but in the end this worked for me:
I did the export using the default options.
I opened the file in Dreamweaver (it seems to handle the length file better than Notepad++)
Added the 'USE mydatabaseName;' to the beginning
I removed all commented lines
I removed the 'delimiter $$' lines
I replaced any $$ at the end of lines with ;
I replaced any orphan $$ (on their own on a line) with a space
I replaced all backticks with a space
Uploaded the SQL file to PHPMyAdmin and it finally worked (I tried not doing each of the steps above and if I missed anyone of them, I got one of a number of different flavor syntax errors). Seems to me like PHPMyAdmin's Import/Export system really needs some work.
Caveat: My table, column and procedure names do not include any special characters, spaces or reserved words so I was able to get away without the backticks. If you have anything unusual you will need them.
Related
I am writing SQL to create a trigger for a table in my database. This code should be in a script we can run whenever we spawn a new database.
I have been reading the SQL doc to understand how to do this and eventually came up with a query of this type:
DELIMITER $$
CREATE TRIGGER calendar_event_after_insert AFTER INSERT
ON calendar_event
FOR EACH ROW
BEGIN
IF #log_calendar_event_id = 'YES'
THEN
...
END IF;
IF #log_calendar_event_name = 'YES'
THEN
...
END IF;
...
END
$$
DELIMITER ;
Now I am getting an error on my use of DELIMITER, and I admit I don't understand much of how that works. My basic understanding is that since there are multiple queries inside this big one that all end with a ; I need to tell sql when this query ends using another delimiter.
After reading a bit about delimiters this seems like the right syntax to me, and on top of that i have been running this query in sequel pro and it works at times and at times it does not (weird, I know).
So eventually I decided to remove the delimiters part and everything works smoothly. I am a bit worried this will have side effects tho.
So my question is: when are delimiters used? are they useful in my case? if so, what am I doing wrong here?
EDIT as requested in comments
This is the error I get when running the query:
You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near 'DELIMITER $$ CREATE TRIGGER calendar_event_after_insert AFTER
INSERT ON calenda' at line 1
FYI we have an old version of MYSQL installed on our dev machines -- MYSQL 5.1.73
DELIMITER is not part of the SQL language. It's a command of the official command-line tool:
If you use the mysql client program to define a stored program containing semicolon characters, a problem arises. By default, mysql itself recognizes the semicolon as a statement delimiter, so you must redefine the delimiter temporarily to cause mysql to pass the entire stored program definition to the server.
To redefine the mysql delimiter, use the delimiter command.
There're some third-party programs that also implement a delimiter command in order to be able to run complex MySQL scripts (e.g. HeidiSQL).
If you are running your script in a context that doesn't allow multiple statements (e.g. a typical PHP application) the command will neither exist nor be needed at all.
I'm trying to embrace mySQL commands in the raw form without using phpMyAdmin and I ran into this little issue so far...
I'm just wondering, I can connect to my db using wamp server and some commands won't work without typing \g after. For instance, I can connect, type my password and then immediately if I just try to create a database via:
CREATE DATABASE testing
It pushes me into a newline that looks like so:
mysql> CREATE DATABASE testing
->
1. How do I get back to a regular line to type after this happens? I keep having to close the command prompt and re initiate which is a hassle. 2. Why does it do this? Then when I type the following the command works just fine.
CREATE DATABASE testing \g
OK, now if that were the case I'd just understand and always type \g after everything because I know some things just "ARE" in programming. But then, I can type this line without the \g and it changes databases just fine.
USE firstdb
I haven't tested further on which commands do and don't work with/without the GO command but I thought I'd ask before I confuse myself a million times.
Much appreciated SO community! Thx in advance.
(Also, since I'm new to SO can someone please leave a comment on how to create those code snippets, but in the inline-block format so I don't have to always have to break my code references out onto new lines? Thanks!)
The semicolon ; is the standard statement delimiter in SQL. In the case of MySQL, the server doesn't need to see it, so the command line client doesn't actually send it... but it waits for it, and nothing is sent to the server until a delimiter followed by a newline is encountered.
Exceptions are things that don't get sent to the server, or don't get sent as SQL. (There's another way, other than the USE statement, to change the current database, using a specially-crafted packet, and afaik the MySQL cli still uses that method, which is, I assume, why USE is a strange exception.)
You can change the delimiter to something else. Commonly, you'll see something like this
mysql> DELIMITER $$
This allows you to send SQL to the server that contains a ; en bloc, without the client thinking you were done when it saw what looks like a delimiter. This is used for declaring procedures, functions, triggers, and events. At the end of the statement, or group of statements, each terminated with $$, you set it back.
mysql> DELIMITER ;
Note there's a space before the ;.
While browsing a SQL dump generated by the program SQLYog for a MySQL 5.6.16 database, I noticed that every stored procedure CREATE statement was surrounded by comment characters (/* */). However, the stored procedures were created when the SQL script was executed.
I was surprised both to see the comments surrounding the stored procedure CREATE statements, and then to see that these commented statements were, in fact, executed.
Seeing that this did occur, I assumed that in fact either the SQL standard, MySQL itself, or SQLYog specifically, documents that it supports the execution of at least some commented SQL code.
This caused me to search for the specification documentation laying out the details regarding the fact that some commented code blocks are executed when the SQL script is run. However, a full hour's search (looking, in particular, for the official specification, but secondarily searching for any such documentation for either SQL, MySQL, or SQLYog) has revealed literally only one link that even makes reference to the fact that commented lines of code in the SQL script are, in fact, executed. Here it is: link to reference that commented lines of SQL are executed (including some of the answers).
I'm aware that I am likely missing the obvious here, but I haven't been able to locate the specification for this.
Can someone please confirm, and if so please provide reference to, the formal documentation that states (and describes) the SQL that will be executed even if the '/* */' syntax surrounds the statement/s (whether this be SQL, MySQL, or SQLYog)? Thanks.
It's in the manual, under "Comment Syntax."
http://dev.mysql.com/doc/refman/5.6/en/comments.html
/*! MySQL-specific code */
In this case, MySQL Server parses and executes the code within the comment as it would any other SQL statement, but other SQL servers will ignore the extensions.
...
If you add a version number after the “!” character, the syntax within the comment is executed only if the MySQL version is greater than or equal to the specified version number.
In the case of stored procedures, the entire declaration wrapped, so that if you tried to restore the dump file on a version of MySQL server that's so old it didn't support stored procedures at all, the procedure definitions would be ignored by the server instead of causing the entire restore operation to fail.
I have a large file that contains a mysqldump of a database. I searched for all the semicolons I come up with 378. When I upload the file to phpMyAdmin it reports 379 queries when doing an import. (I know that phpMyAdmin might not be reliable, but I just want to make sure I don't have a problem with the output of mysqldump)
Is there a way to find out what it thinks the extra query is? The dump file is pretty large and I don't want to share the information.
EDIT:
I have posted the database schema at:
http://blastohosting.com/pos_database.sql
It would be great if it could be determined to as why there is an extra query being reported by phpMyAdmin
I can't tell you why, necessarily, but I can say that I got exactly the same results: 378 semicolons, "379 queries executed".
However, here's the weird thing: when I removed the last two lines in the script:
(blank)
-- Dump completed on 2014-02-17 17:52:43
...PMA said "378 queries executed". It's evidently counting that final comment as a "query" even though it's ignored.
A dump file doesn't necessarily contain one semicolon per statement.
Any CREATE TRIGGER or CREATE PROCEDURE or CREATE FUNCTION statements have literal semicolons within their bodies, so it is common practice to change the client's statement terminator to something besides semicolon, to resolve the ambiguity.
So you could be counting semicolons that aren't statement terminators. Likewise, MySQL may recognize more SQL statements executed that didn't use semicolon.
MySQL builtin commands such as DELIMITER, CHARSET, USE, SOURCE, etc. don't need a terminator at all, but they may have one without error. They shouldn't be reported as statements executed by the server, but they may throw off your count of semicolons.
Do you have any semicolons inside string literals or SQL comments?
I am getting the following message while creating a stored procedure in MySQL Workbench:
"Review the SQL script to be applied on the database"
I have several tables inside the database but the stored procedure I am writing will be
used only for one table. Since, the SQL script of stored procedure is gonna apply on the whole database, I am wondering if it's gonna affect other tables as well? I don't want other tables to get disturbed because of this script.
Please provide your inputs as I am doing this for the first time.
Question #2:
Why do I see "DELIMITER $$" as the first statement while creating a routine before the following statement?
CREATE PROCEDURE `mydatabase`.`myfirstroutine` ()
BEGIN
Thanks
1) MySQL Workbench offers the option to review the generated SQL script before it is sent to the server. This way you can check it for possible problems.
2) The DELIMITER command is usually necessary to switch the current delimiter that ends a single statement (which is by default a semicolon) to something else because the stored procedure code itself needs the semicolon to separate individual commands. However the sp code must be sent as a whole to the server.
A few more details: the DELIMITER keywword is a client keyword only, that means the server doesn't know it and doesn't need it. It's an invention for clients to properly separate sql commands before sending them to the server (you cannot send a list of commands to a server, only individual statements).
In MySQL Workbench however, especially in the object editors where you edit e.g. the sp text, adding the DELIMITER command is essentially nonsense, because there's only this sp code, hence nothing to separate. This might disappear in future version but for now just ignore it.