INSERT problem

Sanders Kaufman wrote:
> Carl Pearson wrote:
>
>> This does not seem to be accurate. At least as far back as MySQL
>> version 3.23, double-quotes are most certainly acceptable for
>> enclosing strings. Section 9.1.1 of the manual details this:
>
> Yeah, it is. I recently lost an argument I was very confident about -
> that double-quotes is actually the ANSI standard. I got so used to
> using double-quotes, I forgot they were the wrong way to do strings.

Well, as this is a mySQL list, and the manual says strings may be
surrounded by single or double quotes, I'd say they are quite legal.

This is all moot anyway, as I was incorrectly equating table defs
surrounded by quotes to be strings, which they are not.

So far as ANSI vs MySQL, You're talking style here, not syntax. "Wrong
way" has no meaning if the statement as run produces valid output.

BTW, found the real problem in the original post. Darn those ticks!

>At least your statement above is *half* right. I was looking at the
>wrong section, 9.1.1 (which defines what a string can be), not 9.2
>(which defines what table, index, column & alias names can be).
>
>But 9.2 does also state:
> An identifier may be quoted or unquoted.
>
>The only exception would be using reserved words, but 'id' and
>'countries' are not on that list.
>
>Still, saying that surrounding table names with quotes is 'required' is
>not true.

There are lots more places than reserved words that require ``
around table names. For example, table names containing spaces.
Or table names that look like numbers. Or table names containing
punctuation.

Carl Pearson <jman_spam_trap_.org@gmail.com> wrote:
....

> So, to re-cap:
> Backticks only for enclosing table & field names, NOT data!
> Single OR double quotes around data are OK - even numbers!
>
> This may not be the *preferred* way, but it's legal syntax.
>
> Now, tiny rant here...
>
> Yes, you are correct that backticks are allowed to identify table names,
> and I thank you for getting me to look a little harder to discover that.
>
> But, this is a MySQL list, NOT an ANSI SQL list, and double-quotes -
> whether or not you disagree with using them - are valid syntax in MySQL.

Careful!

Beginning with 5.0 MySQL knows of the so-called server SQL mode. If you
have ANSI_QUOTES in effect, MySQL uses ANSI style quoting rules (string
literals using single quotes and identifiers using double quotes).

Same goes for escaping: traditionally MySQL uses the backslash to
escape the quote character in a string literal. i.e. 'L\'Oreal'. Now
you can have SQL mode NO_BACKSLASH_ESCAPES, making the backslash an
ordinary character. To escape the quote character, you have to double
it now: 'L''Oreal'.

So whenever you refer to "correct" quoting in MySQL, make sure to
mention the SQL mode in use.

http://dev.mysql.com/doc/refman/5.0/...-sql-mode.html


XL
--
Axel Schwenke, Support Engineer, MySQL AB

Online User Manual: http://dev.mysql.com/doc/refman/5.0/en/
MySQL User Forums: http://forums.mysql.com/

Axel Schwenke wrote:
> Careful!
>
> Beginning with 5.0 MySQL knows of the so-called server SQL mode. If you
> have ANSI_QUOTES in effect, MySQL uses ANSI style quoting rules (string
> literals using single quotes and identifiers using double quotes).

Thanks for that info, I'd been thinking there may have been some
difference between the original poster's setup & mine, but never said as
much.

Did all my testing for this little exercise on my home box, like I said
5.0.27-community, with the default of no mode set.

Also, an apology to Mr. Stuckle, was not looking closely enough at the
data in the original post, it was normal single quotes, not backticks.

So, still confusing why backticking the table & field names at the
beginning of the INSERT made it bomb out. Escaping the single quote
within country 54 was needed, sure, but any attempt at backticking
either "countries", "id", or "country" in

INSERT INTO countries (id,country) VALUES

caused error 1064 (Syntax). This was either via CLI, or phpMyAdmin.

Go figure. The only other variable I can see is that I touch-type in
Dvorak, but ASCII 96 (decimal) still produces the backtick like it's
supposed to.

Perhaps it's a M$ plot! ;)

(Of course, now that I've said that, suddenly the insert is working with
the backticks. So perhaps the whole problem really was only not escaping
the single quote within country 54, but I swear I tried it 6 ways to
Sunday & the backticks weren't working. Very confusing!)

Carl Pearson wrote:
> Sanders Kaufman wrote:

> Well, as this is a mySQL list, and the manual says strings may be
> surrounded by single or double quotes, I'd say they are quite legal.

It also shows how you can setup MySQL to not make that mistake.

The double-quotes are not a way to enclose strings.
They are a way MySQL forgives users who make mistakes.


> So far as ANSI vs MySQL, You're talking style here, not syntax. "Wrong
> way" has no meaning if the statement as run produces valid output.

Yah - but then some fellow comes along and sets MySQL to enforce
standards and suddenly you find that your Wrong Way doesn't work
anymore.

Sanders Kaufman wrote:
> Carl Pearson wrote:
>> Sanders Kaufman wrote:
>
>> Well, as this is a mySQL list, and the manual says strings may be
>> surrounded by single or double quotes, I'd say they are quite legal.
>
> It also shows how you can setup MySQL to not make that mistake.
>
> The double-quotes are not a way to enclose strings.
> They are a way MySQL forgives users who make mistakes.

Uhm, the manual says it's OK. So, it's OK. ANSI & MySQL specs are
different, one must respect & adapt to what the respective authors
allow. It is by definition not a "mistake" if you follow the allowed
syntax!

I understand what you're trying to say, that one should not write
anything but strict ANSI SQL code. Alas for your attitude, the authors
of MySQL must have had a different idea.

>
>
>> So far as ANSI vs MySQL, You're talking style here, not syntax.
>> "Wrong way" has no meaning if the statement as run produces valid output.
>
> Yah - but then some fellow comes along and sets MySQL to enforce
> standards and suddenly you find that your Wrong Way doesn't work anymore.

So he turns the standards back off & continues on his merry way.

Again, it matters not one whit that ANSI does not allow the
double-quote, but MySQL does. This is not an ANSI SQL list; it simply
does not matter if double-quotes are used to enclose strings in MySQL,
as the language allows them.

Let's say the new guy inherits some code, decides to change modes, and
it breaks the code. Happens all the time.

At this point, he has three choices:

Come up to speed with what the (to him) new dialect.

Grab his favorite regex-friendly text editor & get to work.

Find a new job.


Again, MySQL says double-quotes are OK for strings. It's irrelevant
that for ANSI, they're not. Yes, it is that simple!

Geez!