Hello

I asked this question a few days ago but am not getting any further
suggestions so am trying again!

I have just exported a table as .sql from one server and imported it
into mysql on another server.

The table seems to have loaded OK but I see the following

--------------------
Error
SQL query:

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;

MySqL said
#1064
-----------------------

A few other bits of information

1. These statements are in the exported sql file;

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;

2. the error message when importing the sql file has

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;

note the 2 extra @ symbols in the error message?

3. The mysql server for the export is version 5.1.56 - that for the
import is v5.0.18-max.


4. re the 1064 which I am told indicates a parse error.

I clicked on the help icon next to the 1064 but this gave no info.


5. I exported as an sql file. Looking at the options I see

(i) Output

character set utf-8

(ii) Format specific options

display comments

(iii) Object creation options

the following are selected;

add create procedure / funtion / event statement
create table options / if not exist / auto_increment

6. For the import I select SQL and next to this it states "this format
has no options".

I would like to be sure that the table has indeed been imported
correctly and that the error message is not important!

Any thoughts?!

Cheers

Geoff

Geoff <geoff (AT) invalid (DOT) invalid> wrote:

Your question lacks the necessary details.

"Exported" with which tool? How exactly? (options used etc.)
What version of MySQL is running on the respective servers?

This is in no way complete. Error #1064 is an SQL parser error.
The expected error message would be:

syntax error near '<query string>' at line <line# in the file>

This looks like an SQL dump created by mysqldump. And yes, those
lines are near the beginning of a dump file. Depending on the
MySQL version used to import the file, those lines will be
executed as SQL statements (to save the connection character set
before setting it to utf8) or ignored as comments.

Such a line is near the end of a dump file. It restores the
connection character set. Again only if the version of MySQL is
capable of that.

You have not shown any error message yet.

Heh! Information! (at last)

Those versions should work. Nothing has (incompatibly) changed
between those versions with respect to the SQL subset used by
mysqldump. If you want to be 100% safe, use mysqldump from the
5.0 version to create the dump file.

"help icon"? You lost me.

This sounds like you use some GUI tool. Workbench?

GUI tools are notoriously buggy and - by design - conceal relevant
information from the user (the excuse is "this makes it easier for
the average [read: stupid] user")

I suggest to use "mysqldump" to export the table. And "mysql" to
import the dump. RTFM for details.


XL

On Fri, 30 Dec 2011 12:00:47 +0100, Axel Schwenke
<axel.schwenke (AT) gmx (DOT) de> wrote:

Axel

You did find some detail further down but I should have made clear
that I was using phpMyAdmin (verson 3.4.5) to export and then
phpMyAdmin (version 2.8.0.1)to import the data.

Perhaps the problem was caused by these differences?

Re the #1064 - there was no further info given and on clicking the
"help" icon next to the the #1064, again, no further info given.

Cheers

Geoff

On 30-12-2011 18:56, Geoff wrote:
It surely is possible...

You better try to use the same version on both machines,
and this is also true for your database version.

--
Luuk

On Fri, 30 Dec 2011 20:16:01 +0100, Luuk <Luuk (AT) invalid (DOT) lan> wrote:

Luuk

Cann't do that I'm afraid as both servers are out of my control!

Cheers

Geoff

Geoff <geoff (AT) invalid (DOT) invalid> wrote:
This is indeed quite likely. Also per rule of thumb you should *never*
use a newer version of some software to write a file and then an older
version to read that same file. The bigger the difference in version
numbers is, the more likely you will face incompatibilies.

Besides that phpMyAdmin is notorious for being buggy beyond repair and
in fact it is declared a non-topic in many MySQL channels.
So do yourself a favour and switch to sane tools.


XL

On 12/30/2011 6:16 PM, Axel Schwenke wrote:
PHPMyAdmin works fine most of the time. It's a lot better than
MySQLWorkbench, for instance. And a hell of a lot better than trying to
use the CLI.

Maybe you don't like it - but it's the best GUI around right now.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

On Sat, 31 Dec 2011 00:16:06 +0100, Axel Schwenke
<axel.schwenke (AT) gmx (DOT) de> wrote:

Axel

can you suggest one of these sane tools?!

Cheers

Geoff

On Fri, 30 Dec 2011 19:30:35 -0500, Jerry Stuckle
<jstucklex (AT) attglobal (DOT) net> wrote:

Jerry

would you be bothered by the error message?

I have just remembered that I exported 3 other files using the same
method and none of them gave an error message when imported....what
does that say?

Cheers

Geoff

Geoff <geoff (AT) invalid (DOT) invalid> wrote:
Well, the command line tools coming with MySQL would be a natural
choice. And I also recommend the Percona Tools (former Maatkit).


XL