Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 6778
  • Last Modified:

Error Code: 1064 - You have an error in your SQL syntax;

Hello Experts,

now...after long time having used MySQL, I still can't understand the following:
I do create a dump file in order to insert that one to a newly created database.
So far so simple.
For this I use phpMyAdmin
When I try to import that file to the new database, always this error returns:

Error Code: 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '
CREATE TABLE `ANY TABLE` (`ANY TABLE_id` int(11) NOT NULL auto_increme' at line 1

I will never understand how what these guys from phpMyAdmin have been thinking
The same app produces the dump but the same app returns an error while importing. I WILL NEVER UNDERSTAND THIS!

I used any php script to run the import, used navicat and any other software ( like SQLYok...ect) Always the same error.
Import works only if I do this manually running queries (copy/paste)

Now please.....what the ** is this error?
And how finally can I import my dumped files? How do you do this?

I'm running on Windows 2003, MySQL 4.1.12
0
sh2gr
Asked:
sh2gr
  • 2
  • 2
2 Solutions
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
>The same app produces the dump but the same app returns an error while importing.
actually, this is wrong. phpmyadm calls the mysqldump command line tool that generates the script!

this error looks like that there is some special character before the CREATE TABLE script...
0
 
sh2grAuthor Commented:
Angel,

we have been trough this in one of my previous post.
I don't want to go deeper in who calls what etc. What does that mean? that phpMyAdmin does whatever it wants?
My opnion on that is, that whoever, whatever genarates the dump....should genarate it in order to be available error free for import.
And however....is there a need to place any special characters in front/behind/above...to make peoples life more difficult?
I mean...you understand what the logical approach should be....and it is not!


This is a part of the dump, even when deleting the -- comments, I get the error



-- --------------------------------------------------------

--
-- Table structure for table `address_book`
--

CREATE TABLE `address_book` (`address_book_id` int(11) NOT NULL auto_increment,
  `customers_id` int(11) NOT NULL default '0',
  `entry_gender` char(1) NOT NULL default '',
  `entry_company` varchar(32) default NULL,
  `entry_tva_intracom` varchar(32) default NULL,
  `entry_firstname` varchar(32) NOT NULL default '',
  `entry_lastname` varchar(32) NOT NULL default '',
  `entry_street_address` varchar(64) NOT NULL default '',
  `entry_suburb` varchar(32) default NULL,
  `entry_postcode` varchar(10) NOT NULL default '',
  `entry_city` varchar(32) NOT NULL default '',
  `entry_state` varchar(32) default NULL,
  `entry_country_id` int(11) NOT NULL default '0',
  `entry_zone_id` int(11) NOT NULL default '0',
  PRIMARY KEY  (`address_book_id`),
  KEY `idx_address_book_customers_id_zen` (`customers_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=36 ;

--
-- Dumping data for table `address_book`
--
0
 
NovaDenizenCommented:
The table that causes the error, is it the first table in the dump file?  I think the "'" might be part of a previous INSERT statement with improperly escaped characters.
0
 
sh2grAuthor Commented:
These people (the phpMyAdmin & MySQL Staff) are working hard to release new versions.....
and they never thought about the simpliest detail :
To offer a "split file" for larger data import, for heavy files.
Instead they let people run into support forums, sometimes make things worse.

There was no special character, there is only a special "developers virus" which makes the dev's forget that their developed tool has to be user friendly even for their mom

I split my file in to 4 pieces and all errors disapeared, the import was a 3 minutes job.
And I can not say that it was a big file (7 MB)

Thank you for your efforts....I think it will be wise to split the points
0
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
Glad you found a solution.

you should not be angry too much on the developers of phpmyadmin, don't forget that they wrote it for FREE !!!
note that you should not use phpmyadmin for large scripts, but rather use the command line tool mysql directly.

I had also many problems with large script with phpmyadmin, no longer using it for large scripts.

angelIII


0

Featured Post

Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now