MySQL Bugs: #2344: Mysql batch import will not import .sql that have #comments in them.

Bug #2344	Mysql batch import will not import .sql that have #comments in them.
Submitted:	10 Jan 2004 12:26	Modified:	10 Feb 2004 15:30
Reporter:	Matthew Dominick	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Command-line Clients	Severity:	S2 (Serious)
Version:		OS:	Linux (Linux, MacOS X, Unit)
Assigned to:		CPU Architecture:	Any

Description:
When using mysql in batch mode there is an odd requirement that cost me hours.  Your .sql file cannot contain any #comment lines.  Delete them and importing will be a breeze.  There is no indication that this is the problem.  However, experimentation revealed this to be the cause.  

How to repeat:
Attempt to batch import a .sql with #comments and there will be no idication that the action wasn't 
taken except that the results are not seen upon inspection.  Repeat without the comment lines and 
it 
works.

Can you provide an example batch file and show
the command you used to process it? I do not
observe any problems when processing batch
files with comments.

This is the command I used.  

mysql -uusername -ppassword -t database_name < path_to_file/filename.sql

I have pasted part of the .sql file below.  There are quite a few more records but this should be 
good enough for the example.  When I remove the commented lines I am able to use the command 
line above.  Otherwise nothing happens with no error code given.  

# phpMyAdmin SQL Dump
# version 2.5.3-rc3
# http://www.phpmyadmin.net
#
# Host: localhost
# Generation Time: Jan 10, 2004 at 10:48 AM
# Server version: 4.0.13
# PHP Version: 4.3.2
# 
# Database : `zip_codes`
# 

# --------------------------------------------------------

#
# Table structure for table `zipcodes`
#

DROP TABLE IF EXISTS zipcodes;
CREATE TABLE zipcodes (
  zip int(6) NOT NULL default '0',
  state char(2) NOT NULL default '',
  city varchar(200) NOT NULL default '',
  longitude float(10,2) NOT NULL default '0.00',
  latitude float(10,2) NOT NULL default '0.00',
  PRIMARY KEY  (zip)
) TYPE=ISAM PACK_KEYS=1;

#
# Dumping data for table `zipcodes`
#

INSERT INTO zipcodes VALUES (401, 'NY', 'Pleasantville', '41.08', '-73.47');
INSERT INTO zipcodes VALUES (501, 'NY', 'Holtsville', '40.49', '-73.02');
INSERT INTO zipcodes VALUES (544, 'NY', 'Holtsville', '40.49', '-73.02');
INSERT INTO zipcodes VALUES (601, 'PR', 'Adjuntas', '18.10', '-66.43');
INSERT INTO zipcodes VALUES (602, 'PR', 'Aguada', '18.23', '-67.11');
INSERT INTO zipcodes VALUES (603, 'PR', 'Aguadilla', '18.25', '-67.09');
INSERT INTO zipcodes VALUES (604, 'PR', 'Aguadilla', '18.25', '-67.09');
INSERT INTO zipcodes VALUES (605, 'PR', 'Aguadilla', '18.25', '-67.09');
INSERT INTO zipcodes VALUES (607, 'PR', 'Aguas Buenas', '18.15', '-66.06');
INSERT INTO zipcodes VALUES (608, 'PR', 'Aguirre', '0.00', '0.00');
INSERT INTO zipcodes VALUES (609, 'PR', 'Aibonito', '18.08', '-66.16');

I tried the file. mysql processed it without problem.
The contents of zipcodes were:

mysql> select * from zipcodes;
+-----+-------+---------------+-----------+----------+
| zip | state | city          | longitude | latitude |
+-----+-------+---------------+-----------+----------+
| 401 | NY    | Pleasantville |     41.08 |   -73.47 |
| 501 | NY    | Holtsville    |     40.49 |   -73.02 |
| 544 | NY    | Holtsville    |     40.49 |   -73.02 |
| 601 | PR    | Adjuntas      |     18.10 |   -66.43 |
| 602 | PR    | Aguada        |     18.23 |   -67.11 |
| 603 | PR    | Aguadilla     |     18.25 |   -67.09 |
| 604 | PR    | Aguadilla     |     18.25 |   -67.09 |
| 605 | PR    | Aguadilla     |     18.25 |   -67.09 |
| 607 | PR    | Aguas Buenas  |     18.15 |   -66.06 |
| 608 | PR    | Aguirre       |      0.00 |     0.00 |
| 609 | PR    | Aibonito      |     18.08 |   -66.16 |
+-----+-------+---------------+-----------+----------+
11 rows in set (0.00 sec)

What version of MySQL are you using when you attempt to load
the file?

[MSDG4:~] matt% mysql -V
mysql  Ver 12.20 Distrib 4.0.13, for apple-darwin6.6 (powerpc)

This was the version I was using for the example.  It has done the same thing though on other 
machines.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".