Errors upon attempt to export / import database

[jerseyjoe]

I have a CC 3.0.15 installed in .../store. Its db is _storedb.

I want to move the site to a new folder on the same domain called .../shop with a db named _shopdb. The new store is using 3.0.16.

So, after a successful installation of CC3.0.16 in .../shop, I exported the data from _storedb to my hard disk as a CSV. So far, so good.

But when I tried to import that file of data from _storedb.csv into the new _shopdb, I get the following SQL error.

Error

SQL query:

& quot;

MySQL said: Documentation

#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 '"' at line 1

Aside from the obvious fact that it makes no sense that I can't import back into a new db whose structure I expect to be a virtual copy of the original db, the error message itself is opaque to me. I mean, even if the server version has been updated between the time I created the first db and this one created today, should they be so different that I can't import data from one to the other in the same domain?

Anyone have clue to help me with this, please?

TIA

[Guest]

I am not sure if you are exporting/importing the entire database or individual tables within the database.

If the former then I cannot comment, but if you are importing individual tables like your inventory and catagory tables then this is something I have done.

I found that the export to excel csv. file worked well but like you I could not import the excel file back into MySQL. although I had a different error.

I found that whilst I could see the data in excel and save it as a csv. file. There were always errors in importing. I got round the problem by opening the file in a access database table and exporting that to a csv file from there. That way you get more export options than excel gives you, and it was easier (relatively speaking as there were still minor problems). You can make sure that files are terminated by the same charactors etc. in access.

Someone else suggested to me using a text editor like "Crimson Editor" to edit the csv. file. I haven't tried that yet myself but it might be easier if you haven't got access,

[jerseyjoe]

Thanks for your reply.

The situation just moved from inconvenient to farce to tragedy.

I have a CSV copy of the entire db. I also have a copy in SQL. Both were exported from the copy on the server.

Somehow, in the process of making those copies, I deleted the data from the db itself on the server.

But, no problemo, right? I have those copies, right?

All I need do is import one of those copies back into the db on the server, right?

But, noooooo-oh.

Same error message as above. I can't even import back what I exported. On the face of it, the alleged error would have had to have been introduced by phpMyadmin itself.

Does anyone have any idea as to what is going on that I ain't even restore the data?

EDIT UPDATE - before replying, see my next post for the results of my desperation

[jerseyjoe]

Oh, the frustrations of dealing with an obedient idiot (my definition of "computer" and "computer software").

And oh, the satisfaction that is exceeded only by illicit sex, when I can outsmart one of them.

My early attempts at importing the CSV file met with the previously reported error. So, I tried importing from the SQL version of the copy.

That generated an error reporting that the import was stopped because tabe xyz already exists on the server. I deduced that phpMYadmin is such a total idiot that it doesn't know that it's OK to overwrite a existing table while importing. (If there is a setting that informs our stupid servant of that intention, I never saw it.)

So I opened the Structure screen of the problem dB and saw the 29 tables there. I deleted every single table.

When that was accomplished, I again attempted an import of the SQL copy of the dB from my hard drive.

It worked. The obedient idiot created the dB with the required 29 tables that CC needs - and populated them with the data that had seemed lost.

THEN - I went and did the same thing to the second data base for the new CC installation in the _shop folder. The trick worked again.

Idiots. That's all these collections of plastic and conductive pathways known as computers are.

Friggin' idiots.