INSERT problem

[abracad_1999]

I am trying to populate a table with the following insert query run
through phpmyadmin. When I attempt to run it phpmyadmin just freezes.
After a while "Fatal error: Maximum execution time of 300 seconds
exceeded in /web/myadmin/283/libraries/import.lib.php on line 19"
appears but no indication as why the command fails. Any advice most
welcome.

INSERT INTO `countries` ( `id` , `country` ) VALUES ('1',
'Abkhazia'), ('2', 'Afghanistan'), ('3', 'Akrotiri and Dhekelia'),
('4', 'Åland'), ('5', 'Albania'), ('6', 'Algeria'), ('7', 'American
Samoa'), ('8', 'Andorra'), ('9', 'Angola'), ('10', 'Anguilla'), ('11',
'Antigua and Barbuda '), ('12', 'Argentina'), ('13', 'Armenia'),
('14', 'Aruba'), ('15', 'Ascension Island'), ('16', 'Australia'),
('17', 'Austria'), ('18', 'Azerbaijan'), ('19', 'Bahamas, The'),
('20', 'Bahrain'), ('21', 'Bangladesh'), ('22', 'Barbados '), ('23',
'Belarus'), ('24', 'Belgium'), ('25', 'Belize '), ('26', 'Benin'),
('27', 'Bermuda'), ('28', 'Bhutan'), ('29', 'Bolivia'), ('30', 'Bosnia
and Herzegovina'), ('31', 'Botswana'), ('32', 'Brazil'), ('33',
'Brunei'), ('34', 'Bulgaria'), ('35', 'Burkina Faso '), ('36',
'Burundi'), ('37', 'Cambodia'), ('38', 'Cameroon'), ('39', 'Canada'),
('40', 'Cape Verde'), ('41', 'Cayman Islands'), ('42', 'Central
African Republic'), ('43', 'Chad'), ('44', 'Chile'), ('45', 'China'),
('46', 'Christmas Island'), ('47', 'Cocos Islands'), ('48',
'Colombia'), ('49', 'Comoros'), ('50', 'Congo, Democratic Republic
of'), ('51', 'Congo, Republic of'), ('52', 'Cook Islands'), ('53',
'Costa Rica'), ('54', 'Côte d'Ivoire'), ('55', 'Croatia'), ('56',
'Cuba'), ('57', 'Cyprus'), ('58', 'Czech Republic'), ('59',
'Denmark'), ('60', 'Djibouti'), ('61', 'Dominica'), ('62', 'Dominican
Republic '), ('63', 'Ecuador'), ('64', 'Egypt'), ('65', 'El
Salvador'), ('66', 'Equatorial Guinea'), ('67', 'Eritrea'), ('68',
'Estonia'), ('69', 'Ethiopia'), ('70', 'Falkland Islands'), ('71',
'Faroe Islands'), ('72', 'Fiji'), ('73', 'Finland'), ('74', 'France'),
('75', 'French Polynesia'), ('76', 'Gabon'), ('77', 'Gambia, The'),
('78', 'Georgia'), ('79', 'Germany'), ('80', 'Ghana'), ('81',
'Gibraltar'), ('82', 'Greece'), ('83', 'Greenland'), ('84', 'Grenada
'), ('85', 'Guam'), ('86', 'Guatemala'), ('87', 'Guernsey'), ('88',
'Guinea'), ('89', 'Guinea-Bissau'), ('90', 'Guyana'), ('91', 'Haiti'),
('92', 'Honduras'), ('93', 'Hong Kong'), ('94', 'Hungary'), ('95',
'Iceland'), ('96', 'India'), ('97', 'Indonesia'), ('98', 'Iran'),
('99', 'Iraq'), ('100', 'Ireland'), ('101', 'Isle of Man'), ('102',
'Israel'), ('103', 'Italy'), ('104', 'Jamaica '), ('105', 'Japan '),
('106', 'Jersey'), ('107', 'Jordan'), ('108', 'Kazakhstan'), ('109',
'Kenya'), ('110', 'Kiribati'), ('111', 'Kosovo'), ('112', 'Kuwait'),
('113', 'Kyrgyzstan'), ('114', 'Laos'), ('115', 'Latvia'), ('116',
'Lebanon'), ('117', 'Lesotho'), ('118', 'Liberia'), ('119', 'Libya'),
('120', 'Liechtenstein' ), ('121', 'Lithuania'), ('122', 'Luxembourg'),
('123', 'Macao'), ('124', 'Madagascar'), ('125', 'Malawi'), ('126',
'Malaysia '), ('127', 'Maldives'), ('128', 'Mali'), ('129', 'Malta'),
('130', 'Marshall Islands'), ('131', 'Mauritania'), ('132',
'Mauritius'), ('133', 'Mayotte'), ('134', 'Mexico'), ('135',
'Micronesia'), ('136', 'Moldova'), ('137', 'Monaco'), ('138',
'Mongolia '), ('139', 'Montenegro'), ('140', 'Montserrat'), ('141',
'Morocco'), ('142', 'Mozambique'), ('143', 'Myanmar'), ('144',
'Nagorno-Karabakh'), ('145', 'Namibia'), ('146', 'Nauru'), ('147',
'Nepal'), ('148', 'Netherlands'), ('149', 'Netherlands Antilles'),
('150', 'New Caledonia'), ('151', 'New Zealand '), ('152',
'Nicaragua'), ('153', 'Niger'), ('154', 'Nigeria'), ('155', 'Niue'),
('156', 'Norfolk Island'), ('157', 'North Korea'), ('158', 'Northern
Cyprus'), ('159', 'Northern Mariana Islands'), ('160', 'Norway'),
('161', 'Oman'), ('162', 'Pakistan'), ('163', 'Palau'), ('164',
'Palestine'), ('165', 'Panama'), ('166', 'Papua New Guinea'), ('167',
'Paraguay'), ('168', 'Peru'), ('169', 'Philippines'), ('170',
'Pitcairn Islands'), ('171', 'Poland'), ('172', 'Portugal'), ('173',
'Pridnestrovie' ), ('174', 'Puerto Rico'), ('175', 'Qatar'), ('176',
'Republic of Macedonia'), ('177', 'Romania '), ('178', 'Russia'),
('179', 'Rwanda'), ('180', 'Saint Helena'), ('181', 'Saint Kitts and
Nevis'), ('182', 'Saint Lucia '), ('183', 'Saint Pierre and
Miquelon'), ('184', 'Saint Vincent & the Grenadines'), ('185',
'Samoa'), ('186', 'San Marino'), ('187', 'São Tomé and Príncipe'),
('188', 'Saudi Arabia'), ('189', 'Senegal'), ('190', 'Serbia'),
('191', 'Seychelles'), ('192', 'Sierra Leone'), ('193', 'Singapore'),
('194', 'Slovakia'), ('195', 'Slovenia'), ('196', 'Solomon Islands '),
('197', 'Somalia'), ('198', 'Somaliland'), ('199', 'South Africa'),
('200', 'South Korea'), ('201', 'South Ossetia'), ('202', 'Spain'),
('203', 'Sri Lanka'), ('204', 'Sudan'), ('205', 'Suriname'), ('206',
'Svalbard'), ('207', 'Swaziland'), ('208', 'Sweden'), ('209',
'Switzerland'), ('210', 'Syria'), ('211', 'Taiwan'), ('212',
'Tajikistan'), ('213', 'Tanzania'), ('214', 'Thailand'), ('215',
'Timor-Leste'), ('216', 'Togo'), ('217', 'Tokelau'), ('218', 'Tonga'),
('219', 'Trinidad and Tobago'), ('220', 'Tristan da Cunha'), ('221',
'Tunisia'), ('222', 'Turkey'), ('223', 'Turkmenistan '), ('224',
'Turks and Caicos Islands'), ('225', 'Tuvalu '), ('226', 'Uganda'),
('227', 'Ukraine '), ('228', 'United Arab Emirates '), ('229', 'United
Kingdom'), ('230', 'United States'), ('231', 'Uruguay'), ('232',
'Uzbekistan'), ('233', 'Vanuatu'), ('234', 'Vatican City'), ('235',
'Venezuela'), ('236', 'Vietnam'), ('237', 'Virgin Islands, British'),
('238', 'Virgin Islands, United States'), ('239', 'Wallis and
Futuna'), ('240', 'Western Sahara'), ('241', 'Yemen'), ('242',
'Zambia'), ('243', 'Zimbabwe');

[Carl Pearson]

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!

[Gordon Burditt]

>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.

[Axel Schwenke]

Carl Pearson <jm************ *****@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_ES CAPES, 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/

[Carl Pearson]

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!)

[Sanders Kaufman]

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.

[Carl Pearson]

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!