I've seen several posts about MySQL error #1210 but I haven't noticed one about errors occurring within phpMyAdmin. Perhaps someone can help.
Using phpMyAdmin, I fill in the GUI form to (for example) drop an obsolete field in an existing table in an existing database. It asks me to confirm that I want to drop the field, and then fails with an error "#1210 - Incorrect arguments to DATA DIRECTORY". There's none of my coding in here, no MySQL queries of mine, just a few boxes ticked and buttons pressed, yet phpMyAdmin gives an error. I get this error with any attempt to alter a table structure.
For this particular job, the table was created with the following (which was generated by an Export from another phpMyAdmin installation)...
CREATE TABLE `choreovote` (
`id` int(11) NOT NULL,
`compyear` year(4) NOT NULL,
`competition` year(4) NOT NULL,
`memberno` smallint(5) UNSIGNED NOT NULL,
`entry_id` int(11) NOT NULL,
`votes` smallint(5) UNSIGNED NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 DATA DIRECTORY='./cloggb_db/' INDEX DIRECTORY='./cloggb_db/';
ALTER TABLE `choreovote` ADD PRIMARY KEY (`id`);
ALTER TABLE `choreovote` MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
COMMIT;
And the phpMyAdmin generated query which is not working is...
ALTER TABLE choreovote DROP compyear;
Does anyone have any idea where I should look?
Many thanks!
I'm testing this on my system, and working off of some hints at DATA DIRECTORY MySQL, I was able to make it work after:
changing to a full path outside the existing MySQL data directory,
creating the intended directory outside of MySQL (in my case, I have shell access and just used mkdir), and
changing permission on the folder such that my MySQL user had permissions to access the folder and create new files.
Once I did all three of those, your SQL query ran successfully.
Related
I have a largish (4GB) database, that I would like to dump, but when using the mysqldump tool (the MariaDB version, Ver 10.19 Distrib 10.4.21-MariaDB, for Linux (x86_64)), my dumping process has always failed at the same table, with the not so helpful error message:
mysqldump: Couldn't execute 'SHOW CREATE TABLE `AffiliateProgramsCampaigns`': Lost connection to MySQL server during query (2013)
I've tried to debug this error, but none of the obvious solutions worked for me, so I did a little experimenting, and found the culprit of my problem. The table in question, contains a VIRTUAL column, which strangely, if I remove, the dump finishes succesfully. I've digged a little more, but found no such error anywhere else relating to dumping MariaDB databases with virtual columns. Adding the --verbose option to the dump, is not helping either, as it gives me no other significant information.
As the query fails at the SHOW CREATE TABLE part, I've figured it has something to do with the structure of the CREATE TABLE query, but when I only try to dump the structure of this database, everything works like a charm. So I am stuck at the moment, trying to solve this issue. I could give up on the virtual column in this specific table, but if there would be any alternative, even a different dump tool, I would more likely go with that solution. Any advice, on how to fix this, or at least how to debug the problem more throughly would be appreciated!
Here are some other debug informations, that could be helpful:
This is the end of the --verbose dump output:
-- Retrieving view structure for table ActionLogReferences...
-- It's base table, skipped
-- Retrieving view structure for table ActionLogs...
-- It's base table, skipped
-- Retrieving view structure for table AffiliatePrograms...
-- It's base table, skipped
-- Retrieving view structure for table AffiliateProgramsCampaigns...
mysqldump: Couldn't execute 'SHOW CREATE TABLE `AffiliateProgramsCampaigns`': Lost connection to MySQL server during query (2013)
And here is the CREATE TABLE syntax for the table in question:
CREATE TABLE `AffiliateProgramsCampaigns` (
`AffiliateProgramsCampaignId` bigint(20) NOT NULL AUTO_INCREMENT,
`Name` varchar(255) NOT NULL,
`Description` tinytext NOT NULL,
`StartDate` datetime NOT NULL,
`EndDate` datetime NOT NULL,
`IsActivated` tinyint(1) NOT NULL DEFAULT 0 COMMENT 'This column shows if this campaign was manually activated.',
`Status` tinyint(4) GENERATED ALWAYS AS (if(`IsActivated`,if(curdate() between `StartDate` and `EndDate`,1,0),0)) VIRTUAL COMMENT 'The final, computed status of the campaign. When querying, you should use this to check the status.',
`affiliatePrograms_AffiliateProgramId` mediumint(9) NOT NULL,
`images_ImageId_BaseImage` bigint(20) DEFAULT NULL COMMENT 'The id of the base image.',
`images_ImageId_CoverImage` bigint(20) DEFAULT NULL COMMENT 'The id of the cover image.',
PRIMARY KEY (`AffiliateProgramsCampaignId`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1
The query that is reported by mysqldump btw runs every single time I try it, both from phpymadmin and from the command line mysql interface. I also tried dumping with different users, even with the root user, but I always get the same error, at the same spot.
The problem was with the CURDATE() function that was used in the virtual column. By changing the function, to CURRENT_TIMESTAMP(), the issue is solved.
Also posted a bug report on the official boards: https://jira.mariadb.org/browse/MDEV-26619
So in this case, I will get the whole database schema multiple times. But everytime the tables structure might be slightly different than the previous one. Since I already have data inside, is there a way to write a query to compare with the existing table and just adding new columns?
For example I already have this table in my database.
CREATE TABLE `Ages` (
`AgeID` int(11) DEFAULT NULL,
`AgeName` varchar(32) DEFAULT NULL,
`AgeAbbreviation` varchar(13) DEFAULT NULL,
`YouthAge` varchar(15) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
And in the new schema that I get has the same table but with different columns.
CREATE TABLE `Ages` (
`AgeID` int(11) DEFAULT NULL,
`AgeName` varchar(32) DEFAULT NULL,
`AgeAbbreviation` varchar(13) DEFAULT NULL,
`YouthAge` varchar(15) DEFAULT NULL,
`AgeLimit` varchar(20) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
In this case the column AgeLimit will be add to the existing table.
You should be able to do it by looking at the table definitions in the metadata tables (information_schema).
You can always look into the existing schema using the information_schema database, which holds the metadata.
You can then import your new schema into a temporary database, creating all tables according to the new schema and then again look into the metadata.
You might be able to use dynamic sql inside a stored procedure to execute alter table statements created from that differences at runtime
But I think, this is a lot easier from the backend nodejs server, because you can easily do step 1 and 2 also from nodejs (it's in fact just querying a bunch of tables) and you have way more possibilities to calculate the differences, create and execute the appropriate queries.
EDIT 1
If you don't have the possiblility of creating a temporary database from the new schema, you will have to find some other way, to extract information from it. I suspect you have a sql-script with (among others) a bunch of CREATE TABLE ... statements, because that's typically what mysqldump creates. So you'll have to parse this script. Again, this seems to be way easier in javascript, if it even is possible in a MySQL stored procedure. If your schema is as well structured as your examples, it's actually just a few lines of code.
EDIT 2
And maybe you can event get some inspiration from here: Compare two MySQL databases There are some tools mentioned which do a synchronization between databases.
Installing Mura on a brand new machine and local MySQL 5.7 database. Per the install instructions I browse to the Mura index.cfm file to complete the installation. I enter in the database and DSN info. After a few seconds I get an error message.
Error Executing Database Query.
Datasource: muracms
SQL: CREATE TABLE
IF NOT EXISTS tuserremotesessions ( userID char(35) default NULL,
authToken char(32) default NULL, data text, created datetime
default NULL, lastAccessed datetime default NULL, PRIMARY KEY
(userID) )
Code: 42000
Type: 42000
All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead
Refreshing browser page results in this error again. I can see that tables have already been created in the database. I have been unsuccessful at attempts to internet search for a solution.
Does anyone have an idea of what I can do to get past this error? I have successfully installed Mura on other servers before so I'm really stumped.
For those who run into this error, it is due to a change in MySql 5.7 from how MySql 5.6 worked. See http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-3.html. Specifically
Columns in a PRIMARY KEY must be NOT NULL, but if declared explicitly
as NULL produced no error. Now an error occurs. For example, a
statement such as CREATE TABLE t (i INT NULL PRIMARY KEY) is rejected.
I edited the create table statements for several tables in {murahome}/requirements/mura/dbUpdates/5.2.0.cfm to remove the default NULL statement on two tables and then everything worked fine.
I have a problem. When I try to edit something in the category area of my opencart isntallation an error shows up saying the table category_path does not exist.
This error usually happens when an upgrade went wrong. Can I simply use a CREATE_TABLE query in my phpmyadmin to fix this, or would that not work?
Hope someone can help me with this.
If you only need to create the category path table it can be created like this (replacing oc_ with your database prefix if necessary):
CREATE TABLE `oc_category_path` (
`category_id` int(11) NOT NULL,
`path_id` int(11) NOT NULL,
`level` int(11) NOT NULL,
PRIMARY KEY (`category_id`,`path_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
You can run that SQL from phpMyAdmin or any other MySQL client. Afterward you can navigate to the Admin > Catalog > Category and click Repair which should generate the necessary records.
Please note, that table is generated by install/upgrade script and it's exactly as you say, probably a botched database upgrade or none at all. If that's the case, bear in mind that you may have other database problems as well and you may benefit by running the upgrade script on your database.
I'm porting a rather simple table to my live db server and it's giving me this strange error when I try to create a InnoDB table, table create is:
CREATE TABLE `cobertura` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`cep` int(8) unsigned zerofill NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `id` (`id`),
KEY `idx_cep` (`cep`)
) ENGINE=InnoDB;
If i change the engine to MyISAM it works, if I change the table name to something else, it works.
If i create the table as MyISAM and do an engine alter to InnoDB I get error 121.
I tried looking on the folder where mysql stores the files to see if there's any trash there, nothing.
Any ideas?
While the database may have a dash (-) in the name it will prevent MariaDB (and therefore MySQL) from setting the engine to InnoDB...though this is at best a half-answer as while I am trying to import an entire database back in to the system there are other tables that get created first without problems. Unfortunately this issue is now forcing itself upon me and I do not have the time to start a whole new database name scheme policy. For now I'm changing the engine for that particular database to use MyISAM instead.
From general troubleshooting try:
SHOW ENGINES;
...and if InnoDB isn't installed apparently then try this:
INSTALL PLUGIN innodb SONAME 'ha_innodb.so';