Okay, so first of all, I am SO sorry if this is an ignorant and stupid question. I have absolutely no knowledge of databases. I have only used them when creating and uploading Wordpress sites, and it works if everything goes without any errors.
So here is my problem:
I've created a Wordpress website on a local server. I've done the usual, exported the database, tried to upload it on the live server, but there seems to be an error.
I get the #1064 error.
1064 - You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '?' at line 59
Half of the tables do not import on the live server. Here's what I've already tried:
Exporting the tables with the "Enclose export in a transaction" and "Disable foreign key checks" checked.
Exporting in two files with and without the mentioned options checked. This way I got more tables, and the wp_options table got
full instead of empty, but still only 15 tables instead of 23.
I checked to see if the "TYPE" syntax is "ENGINE" and it seems fine to my unknowing eyes.
I am a total ignorant when databases are concerned. I don't know what to check anymore. My guess is that the live server uses MariaDB and it is somehow not compatible with the SQL I'm trying to upload.
I tried to see the line 59, but there is no "?" there, at least not where I'm looking at. It might be that I'm looking at the wrong place, the blond that I am.
Here's the code around the line 59 when database is opened in editor.
--
-- Table structure for table `wp_gg_folders`
--
CREATE TABLE `wp_gg_folders` (
`id` int(11) NOT NULL,
`title` varchar(255) NOT NULL,
`date` datetime NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
I tried to see the MariaDB's documentation and the possible way to deal with any incompatibility would be to update my MySQL. I have no idea how to do it.
Oh and btw. I already have a working website on this server but with an older version of Wordpress, so if it's an old SQL version, why is it working there?
This turned out to be long... sorry. And thanks in advance!
Edit: I discovered there is a problem with exporting. In the exported file, there are always last third of the tables missing. I have no idea why. Can I somehow get the tables/whole database manually, and not through PhpMyAdmin?
Okay guys and girls, I've found the solution.
The problem was not in any error, it was in exporting the database at the very beginning, therefore, importing showed different kinds of errors each time I tried to import the database.
The query, while exporting would abort the export causing only part of the tables to be exported. By changing the length of the query while doing the export, I solved the problem.
Instead of 50000, I wrote in 1047551.
Here's the article that helped me, with screenshots:
https://wpengine.com/support/exporting-database/
Related
I had a DB with some values and for some reasons I had to clear the content of all tables. Then I changed the structure of my tables and I wanted to add the new data to populate my tables.
In order to add the data I do basically like here. Here is what I get, I saw on the internet that it was a problem with my version on Mysql workbench but I never had any problem when I did that previously so I'm kinda not sure where is the real problem.
Ok I get the error, it definitely was not a MySQL version.
I was importing one table in a MySQL Server when the power went down. After this event I tried to query the table I was importing, but got the error 2013, only when I'm querying this table (the others work just fine).
I have physical access to the server, tried to execute any query from there (tried to SELECT, and even DROP TABLE) but still got the same error.
Does anybody know a solution where I can re-build only the table (without building the whole schema from scratch?)
I'm adding this as an answer rather than having lots of comments underneath. I must state in advance that I've not used MySQL but I have used SQL server a lot so I'm hoping that something I say may help.
You say the table is still there. Was it created as part of the operation you were doing or had it been there for a while?
What happens if someone else or a different account tries to access this table?
Is there anything on this page that is relevant to your problem?
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html
I get the following error after attempting to import a Drupal site database dump on my local server.
The import stops at the search_total table. I have looked in search_total for the word "groser" which I have found and isn't duplicated.
On the other hand I have found the word "großer" which leads me to believe that Mysql interprets the "ß" as a "s".
search_total MyISAM utf8_general_ci
Any ideas on how to deal with this issue?
Thanks!
That is a known issue when exporting from an older MySQL version (5.0) to a newer one (5.1) for example. If you don't really care about having the exact same data in your search table (should be irrelevant if you're setting up a local development environment for example), you can ignore these duplicates with the -f flag.
See http://linuxadminzone.com/ignore-mysql-error-while-executing-bulk-statements/
I am having a particularly weird problem putting the data into my production server. My test server runs MySQL 5.1.41. I export the database (tried both via mysqldump and PHPMyAdmin) and then try to import into my production server that runs MySQL 5.0.92.
In one of the tables, I get an error "#1062 - Duplicate entry '1' for key 1". That table has a PRIMARY key and a UNIQUE composite key. When I look into output of phpmyadmin error, I do not see any duplicates.
I already tried:
- exporting with the option "add AUTO INCREMENT"
- checking whether the collations are the same. They are. Besides, the keys in question are numerics.
So if anybody knows what could be causing the error, and how to fix it - I would appreciate it.
Try to remove the index from the table in a dump and then, when all the data will be imported, add it manually.
If everything works fine in the source database, the only thing that I can think of is that the target database doesn't set the appropriate column to AUTO_INCREMENT.
Have you tried creating that table manually in the target database and setting the column in question to AUTO_INCREMENT before importing the source dump?
The the solution was to remove the AUTO_INCREMENT attribute from columns before importing. Still do not understand why, though. The indexes could actually stay. Then the AUTO_INCREMENT could be easily added back. A mixture of what Martin & Silver Light proposed, but I guess none of the answers were exactly right.
On the live server a table was not found mysteriously. I twas working normally but suddenly i got sql error of missing table. I looked through phpmyadmin i found that a table was really missing mysteriously. It happened first time in my MYSQL life.
Can you please tell me what happened, why the table vanished mysteriously?
Maybe a SQL injection attack dropped the table? Have you checked the database logs?