I am starting to learn SQL using MySQL and I got my hands on book "SQL for MySQL Developers: A Comprehensive Tutorial and Reference".
Why the author doesn't place semicolons ; at the end of the statements?
Can you form legal statement in MySQL without using semicolon?
Here is an example pulled right from the book (p.45)
CREATE DATABASE TENNIS. Of course, MySQL shell responds by ->.
Many flavors and applications of SQL require a semi-colon at the end. A few do not.
Related
I need to create a procedure for class, but I think the sql version in the book is VERY old. For example, I don't think I can't use "Create or replace" like the book says, but "create", "drop", "create", but that is beyond the scope.
My issue is that I am having trouble setting the %TYPE. I use WAMP, I created the procedure in Notepad++, and pasted it to the console. I then opened up phpmyadmin, pasted it into the query window, and was rewarded with more verbose error message. Book: "A guide to SQL" by Phil Pratt and Mary Last, Ninth Edition https://www.amazon.com/Guide-SQL-Philip-J-Pratt/dp/111152727X . Book has TAL Distributers, SOLARIS comdominium group, and COLONIAL adventure tours databases it that helps anyone. The instructor provided the sql file to create the databases as a time saver. This is for the last chapter, ch.8 Creation code:
delimiter ;;
use tal;;
CREATE PROCEDURE CHANGE_ITEM_PRICE(I_ITEM_NUM IN item.item_num%TYPE, I_NEW_PRICE IN item.price%TYPE) AS
BEGIN
UPDATE item SET price = I_NEW_PRICE
WHERE item_num = I_ITEM_NUM;
END;;
delimiter ;
2 Errors:
Unrecognized data type. (near "IN" at position 56)
and another for position 91.
Any thoughts? I'm not looking to be spoon fed here, I just need a little guidance please.
Edit: Thank you #Bill Karwin. The corrected working syntax follows:
delimiter ;;
use tal;;
CREATE PROCEDURE CHANGE_ITEM_PRICE(IN I_ITEM_NUM char(4), IN I_NEW_PRICE decimal(6,2))
BEGIN
UPDATE item SET price = I_NEW_PRICE
WHERE item_num = I_ITEM_NUM;
END;;
delimiter ;
I_ITEM_NUM IN item.item_num%TYPE
This is not a valid procedure argument declaration for MySQL. You have to name the type with something like INT or DATE or VARCHAR(length) or another known type. MySQL has no syntax like you show to dynamically query the type of a named column.
Out of curiosity, where did you get that syntax? Is it part of some other brand of SQL database? I've never seen it before.
Aha, I found it:
https://www.postgresql.org/docs/current/static/sql-createfunction.html says:
The type of a column is referenced by writing table_name.column_name%TYPE. Using this feature can sometimes help make a function independent of changes to the definition of a table.
That's in the PostgreSQL documentation. PostgreSQL and MySQL are not the same software, and there are many examples of syntax and features that each has that the other does not.
This syntax is also supported by Oracle: %TYPE attribute. Actually, I assume Oracle did it before PostgreSQL.
Re your comment:
var IN char(4)" does not work either
You said you were interested in a little guidance. The simplest guidance is that when you're learning a new syntax, it helps to read the reference documentation. :-)
I've used MySQL a lot over the past 16 years. I am a regular speaker at MySQL Conferences and users' groups. I'm a published author. And even I open the documentation pages as a first step when I'm doing something that isn't immediately familiar to me.
Here: http://dev.mysql.com/doc/refman/5.7/en/create-procedure.html
Notice when declaring procedure parameters, it's IN param_name type, not param_name IN type.
now the error is "syntax near ' AS....'
Again, refer to the documentation. There's no AS in the stored procedure syntax for MySQL. That's also Oracle syntax.
You may need to get a different book if you're going to use MySQL instead of Oracle. For example, I suggest MySQL Stored Procedure Programming: Building High-Performance Web Applications in MySQL.
But honestly, I am not a fan of using stored procedures in MySQL at all. MySQL's implementation of stored procedures is far inferior to that of Oracle. MySQL procedures have no packages or libraries, there's no procedure debugger, they're not compiled, and they don't scale well.
Most developers who use MySQL put more logic in their application code instead of stored procedures. This allows them to scale out their performance to numerous application servers, instead of piling up the load on the database server.
I don't believe MySQL has an equivalent for Oracle's %TYPE operator. You will need to specify the data types directly, for example:
CREATE PROCEDURE CHANGE_ITEM_PRICE(I_ITEM_NUM INT, I_NEW_PRICE DECIMAL) ...
I checked through the function and operator list in the most recent MySQL manual to see if they have recently added this function, but did not find it there.
As far as I can gather, there are commands which are native to SQL such as SELECT and DELETE, and there are commands which are part of MySQL but not native to SQL such as use and describe. Have I got that right?
In this link the difference seems to be implied by having the MySQL commands in lower case. Is there a resource which shows which commands belong to which group i.e. native SQL vs MySQL-specific?
SQL is a language standard. Defined by organisations like ISO, ANSI, DIN.
Each SQL database system provides SQL, but with different scope and syntax. So you can learn the standard, but than you have to look for the distinctions. Or you directly learn a syntax of a specific database system. It depends on your purposes.
By the way the commands themself are case-insensitive. So it is indifferent if you write "select" or "SELECT". I prefer lower case because it is easy to write. Other prefer upper case because it is easy to read. In many projects the convention is upper case.
Is there any way to use T-SQL queries with MySQL database, like having a data connector that understand TSQL and can connect to MySQL?
Short answer, no.
By the time you've developed or found an interface that could translate T-SQL syntax into MySQL (correctly); you might as well have learnt the syntax required to write the MySQL you need.
It's not all that different to be honest; and it will broaden your knowledge and make you flexible for other types of database query languages.
I'm building a C application, and for the first time using the MySQL API. I did a little research before I began building my application and stumbled upon this SO question, which talks about not putting user data directly into queries and instead using prepared statements to overcome the possibility of SQL injection - which is just fine and dandy.
I've come round to actually coding my application and I feel like I want to slit my wrists. I haven't used prepared statements before (it's so different to what I'm used to doing normally in my other favourite language, PHP - I'm so used to just writing SQL and escaping data). It so happens that I've also stumbled across the function mysql_real_escape_string. My question is - is it just as safe to escape data in an SQL query (an example below) as it is in a prepared statement?
mysql_real_escape_string(dbc, sBuf, sUserInputData, strlen(sUserInputData));
sprintf(sQuery, "SELECT * FROM `sessions` WHERE `SessionID`='%s';", sBuf);
I need to run a RLIKE query on a database mmoved from MySQL to SQL Server 2005 however having problems replicating the "RLIKE" functionality that MySQL provides.
Does anyone have any ideas?
Cheers,
Chris
The only way I know of to do that is to add user defined CLR functions.
To begin with, here's an MSDN Magazine article, "Regular Expressions Make Pattern Matching And Data Extraction Easier"
The code for that article, which I've been using for a couple of years now, is here.