Professional Web Applications Themes

INSERT problem - MySQL

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'), ...

  1. #1

    Default INSERT problem

    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');

    abracad_1999@yahoo.com Guest

  2. #2

    Default Re: INSERT problem

    >I am trying to populate a table with the following insert query run=20 

    PHP has limits on the execution (real) time of a web page. You
    went over it. PHP doesn't know *WHY* it went over the limit, it
    just knows that it did. You can raise the limit in php.ini (then
    restart the web server), but that may be just masking the symptoms
    rather than solving the problem.

    This query doesn't look that big or complicated, although it might
    have gotten mangled by all the equal-sign two zero crap at the end
    of lines. Possibly something else has the table locked? The server
    is very busy doing something else?
     


    Gordon Guest

  3. #3

    Default Re: INSERT problem

    com wrote: 

    There are a couple of problems. First, don't use quotes for your table
    & field names. Do this instead:

    INSERT INTO countries (id, country)

    A couple of other things:

    Country ID's 4, 54 & 187 contain high ASCII values, if they don't import
    properly edit those specific rows & paste in again. If it still doesn't
    work check your collation.

    Also, country ID 54 has a single quote within the name, so you may wish
    to use double-quotes to enclose your values.

    It was a combination of enclosing the table & field defs in quotes, and
    having a single quote in country 54 along with using single quotes as
    your delimiter, that caused the import to fail.
    Carl Guest

  4. #4

    Default Re: INSERT problem

    com wrote: 

    Despite other comments, the backticks around your table and column names
    are fine. They are valid for MySQL.

    If `id` is a numeric value, you should not have quotes around the
    numeric values, i.e. you should have (1, 'Abkhazia').

    Also as noted, the entry with value 54 has a single quote in it.
    Enclosing the values within double quotes is not correct, however - that
    is invalid SQL (strings must be enclosed by single quotes).

    The way to correct this is to have two single quotes in the string, i.e.
    'Côte d''Ivoire'

    The non-ASCII characters (i.e. 'Åland') may or may not be a problem - it
    depends on the table definition.

    I'm not sure why this would give a timeout error, though. It shouldn't
    take long for it to be inserted. I'd recommend you break it up into
    smaller chunks and see what happens. You should be able to determine if
    there are other errors in your SQL that we've missed.

    --
    ==================
    Remove the "x" from my email address
    Jerry Stuckle
    JDS Computer Training Corp.
    net
    ==================
    Jerry Guest

  5. #5

    Default Re: INSERT problem

    Jerry Stuckle 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:

    A string is a sequence of bytes or characters, enclosed within either
    single quote (‘'’) or double quote (‘"’) characters.

    Did fail to mention previously that the quotes as shown in the original
    post were ASCII 60's (96 in decimal), not 27's (decimal 39). That also
    caused my attempt at importing to fail.

    So far as surrounding table names in the insert statement with quotes, I
    couldn't find it in the manual, and it bombed when I tried it. Am
    curious where you got this info.

    And yes, the collation will definitely be an issue. Defining the
    'country' column as utf8_general_ci, the records 4, 54 & 187 did not
    import the country name. Set to ASCII, the high ascii chars imported as
    question marks (Hex code 3F, ASCII 63), but the remainder of the string
    came in OK.
    Carl Guest

  6. #6

    Default Re: INSERT problem

    Carl Pearson wrote:
     

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

  7. #7

    Default Re: INSERT problem

    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:
    >[/ref]

    The SQL standard is to enclose all strings with single quotes.
     

    The quotes around the table and column names were ASCII 96 decimal - a
    backtick, which is correct for MySQL. The ones around the values were
    ASCII 39 decimal, which is again correct.
     

    It requires back ticks. Check the manual. It's there, very
    prominently. And has been since at least version 3.x.
     


    --
    ==================
    Remove the "x" from my email address
    Jerry Stuckle
    JDS Computer Training Corp.
    net
    ==================
    Jerry Guest

  8. #8

    Default Re: INSERT problem

    Sanders Kaufman wrote: 
    >
    > 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.[/ref]

    It may. But I use standard SQL so I have less to change should I need
    to go to a different database. And standard SQL is to use single quotes
    around non-numeric values.

    --
    ==================
    Remove the "x" from my email address
    Jerry Stuckle
    JDS Computer Training Corp.
    net
    ==================
    Jerry Guest

  9. #9

    Default Re: INSERT problem

    Jerry Stuckle wrote: 
    >
    > It requires back ticks. Check the manual. It's there, very
    > prominently. And has been since at least version 3.x.
    >[/ref]

    Allow me to clarify this. If you're going to enclose table and/or
    column names, they must be back ticks. And back ticks are required if
    you're using MySQL reserved words as column or table names.


    --
    ==================
    Remove the "x" from my email address
    Jerry Stuckle
    JDS Computer Training Corp.
    net
    ==================
    Jerry Guest

  10. #10

    Default Re: INSERT problem

    Jerry Stuckle wrote: 
    >>
    >> It requires back ticks. Check the manual. It's there, very
    >> prominently. And has been since at least version 3.x.
    >>[/ref][/ref]

    Time to put this to rest.

    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.
     

    Well, that's certainly what the manual says, but it's not the way it's
    working in practice.

    Locally am on 5.0.27-community, haven't tried any on a web host.

    The insert bombed for me until I took out any form of quoting from the
    table & column names. i.e.,

    Then I took another look at the original post.

    The entire problem was not as I originally stated, having the table &
    field defs in quotes.

    It was actually that back ticks were *also used for the data*.

    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.

    Point is, even though I had a couple of facts about table defs wrong, I
    still got the insert to work! You could have done the same, or at least
    looked a little harder at the problem, rather than just dismiss my
    answer because it had it's own syntax error.
    Carl Guest

  11. #11

    Default Re: INSERT problem

    Sanders Kaufman wrote: 
    >
    > 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.[/ref]

    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!
    Carl Guest

  12. #12

    Default Re: INSERT problem

    >At least your statement above is *half* right. I was looking at the 

    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.

    Gordon Guest

  13. #13

    Default Re: INSERT problem

    Carl Pearson <com> 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).

    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/en/server-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 Guest

  14. #14

    Default Re: INSERT problem

    Axel Schwenke wrote: 

    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 Guest

  15. #15

    Default Re: INSERT problem

    Carl Pearson wrote: 
     

    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.

     

    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 Guest

  16. #16

    Default Re: INSERT problem

    Sanders Kaufman wrote: 

    >
    > 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.[/ref]

    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.
     
    >
    > 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.[/ref]

    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!
    Carl Guest

Similar Threads

  1. Last Insert ID problem
    By Shane930 in forum Coldfusion Database Access
    Replies: 3
    Last Post: October 13th, 08:17 PM
  2. insert problem....
    By someone in forum MySQL
    Replies: 5
    Last Post: September 22nd, 02:42 AM
  3. ' & insert problem
    By Dicky in forum Coldfusion - Advanced Techniques
    Replies: 1
    Last Post: May 25th, 12:17 PM
  4. insert CSV in mySql problem
    By Richard Sauve in forum PHP Development
    Replies: 1
    Last Post: April 30th, 09:05 PM
  5. Problem with insert
    By ASP MS Access insert issue in forum ASP Components
    Replies: 2
    Last Post: April 12th, 02:46 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139