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';
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
I've reduced this as basic as I can. I'm getting the error: "dynamic sql generation for the update command is not supported against a selectcommand that does not return any key column information".
This would normally mean I don't have a primary key. But I do and here is the create table for it (MySQL):
CREATE TABLE `testtable1` (
`test_id` bigint unsigned NOT NULL AUTO_INCREMENT,
`test_label` varchar(10) NOT NULL,
PRIMARY KEY (`test_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
MySQL and such are a fresh install of the latest stable release. My Visual Studio is Community 2019.
I can add the Data Connection in Server Explorer just fine and I can see all two columns. This is the only table in the testdb. The above create statement comes from that connection in fact and it identifies that there is a primary key (test_id). Looking at the column properties in Server Explorer shows the Column Key property having "PRI" in it. Seems like it knows it's the primary key to me.
I go and add a new winform and only put a DataGridView on it. From the Wizard on "Choose Data Source I select Add Project Data Source and pick database, dataset, select the connection string, pick all columns from the table, and click finish.
That's when I get the error.
Can't get much more basic than that. What am I screwing up? Is there some setting in MySQL or Visual Studio that's set wrong? This is my first time trying MySQL and I'm not having any luck.
Gurr, Greg.
:)
Found an answer of sorts. The Unsigned in the MySQL definition was definitely causing the Connector or Visual Studio to choke. Removing it from the column definition allowed it to work correctly.
I can live with a Signed BIGINT primary key column for my table.
-gg
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.
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 have a table 'text' initially create with the following script:
CREATE TABLE IF NOT EXISTS `text` (
`old_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`old_text` mediumblob NOT NULL,
`old_flags` tinyblob NOT NULL,
PRIMARY KEY (`old_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 MAX_ROWS=10000000 AVG_ROW_LENGTH=10240 AUTO_INCREMENT=8500 ;
I would like to compress it.
I tried the following script for this:
ALTER TABLE text ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4;
But the table requires the same disc space after I ran it (I use innodb_file_per_table).
Initially idea appear after using archived to compress backup of tables - compressed size is 2% of original size.
How to perform compression of InnoDB table which reduces disc size required?
Thanks.
Compression does not affect already used space, so the best way to reduce size of all data is to delete the db server data, create tables again using ROW_FORMAT=COMPRESSED and load the data from backup.
I can prove that works, have tested myself.
All neccessary steps are listed here:
http://code.openark.org/blog/mysql/upgrading-to-barracuda-getting-rid-of-huge-ibdata1-file