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.
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
could you please help me? I bought a domain just for learning databases etc. and I created my model of a database in MySQL Workbench. I generated a script and tried importing it into my database using phpMyAdmin. This is the script:
CREATE TABLE IF NOT EXISTS `knight` (
`idKnight` INT NOT NULL AUTO_INCREMENT,
`strength` INT NOT NULL DEFAULT 1,
`agility` INT NOT NULL DEFAULT 1,
`vitality` INT NOT NULL DEFAULT 1,
`attack` INT GENERATED ALWAYS AS (agility*strength) STORED,
`defense` INT GENERATED ALWAYS AS (vitality*strength) STORED,
`idUser` INT NOT NULL,
`idTavern` INT NULL,
PRIMARY KEY (`idKnight`),
INDEX `fk_user_idx` (`idUser` ASC),
INDEX `fk_tavern_idx` (`idTavern` ASC),
CONSTRAINT `fk_user` FOREIGN KEY (`idUser`)
REFERENCES `user` (`idUser`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tavern` FOREIGN KEY (`idTavern`)
REFERENCES `tavern` (`idTavern`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB
And this is the error:
#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 'GENERATED ALWAYS AS (agility*strength) STORED,
defense INT GENERATED ALWAYS ' at line 6
Now the question is how do I synchronize the MySQL Workbench version of a database for which the script is generated, and the database itself. The database is Inno DB.
Thanks for your help
EDIT: MySQL version of my server is: 5.6.28
This type of problem shows the importance of using the same version of database in development as you will eventually use when you deploy to your production server. So you don't get surprised by incompatibilities.
You can run that script against your MySQL 5.6 server only if you avoid SQL features introduced in more recent versions of MySQL. This includes generated columns, which were first introduced in MySQL 5.7.
So you need to remove these columns, or else change them to plain INT columns, without the generated option.
`attack` INT GENERATED ALWAYS AS (agility*strength) STORED,
`defense` INT GENERATED ALWAYS AS (vitality*strength) STORED,
If you need those columns in query result sets, you have a few alternative solutions:
Add them as expressions in the select-list of a SELECT query:
SELECT (agility*strength) AS `attack`, (vitality*strength) AS `defense`
FROM `knight` ...
Or you could create a VIEW to encode a query with those expressions.
Or you could add those columns as plain integers, and write TRIGGERs on INSERT and UPDATE to keep them in sync with the other columns.
MySQL 5.6.28 was released in December 2015, and the whole 5.6 branch is past its end-of-support date. That means if any security bugs are discovered from now on, they won't be fixed. Besides, you're already using an outdated release of 5.6, with many bugs. The last 5.6 release was 5.6.51 in January 2021.
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 developed a database system utilizing MySQL to house some testing data.
CREATE TABLE testtable (
TEST_IDX int(11) NOT NULL AUTO_INCREMENT,
PASS_FLAG bit(1) NOT NULL,
RESULT_STRING varchar(500) NOT NULL,
TEST_DATE timestamp NULL DEFAULT NULL,
LAST_MODDATE timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
TESTED_BY varchar(45) NOT NULL,
PRIMARY KEY (TEST_IDX) )
ENGINE=InnoDB AUTO_INCREMENT=31 DEFAULT CHARSET=latin1;
One of the fields used is a flag to indicate the Pass/Fail Status of a test set. On my development machine I used the BIT data type, developed the database interaction code and tested the system successfully. I have a second development laptop that I used to perform bug fixes and such when deployment time came where the system also worked properly.
When I went to deploy the system on a production machine I set up MySQL and imported the database from a dump made off of the laptop. When the program, which had run successfully on both of my development machines, attempted to execute the error "data too long for column" was generated causing my inserts to fail. This doesn't make sense to me unless mysql has a setting that makes the bit/tinyint/int(1) behave in odd ways from install to install. I was able to make this function properly by simply setting the field to an INT (INT(11) it think) but I should not have had to do this and I would like to know why this happened. Perhaps someone could clarify how BIT data types work in MYSQL.
I am making a website with Drupal 7 on my localhost. Today I got the well-known error that my cache_rules was missing. I tried to restore it. That seemd to have worked, because I see the table in my database now. However, PHPMyadmin said after the query that the 'results came back empty'. Is this correct.
I used this code to restore it:
CREATE TABLE IF NOT EXISTS `XX_cache_rules` (`cid` varchar(255) NOT NULL DEFAULT '' COMMENT 'Primary Key: Unique cache ID.', `data` longblob COMMENT 'A collection of data to cache.', `expire` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.', `created` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry was created.', `serialized` smallint(6) NOT NULL DEFAULT '0' COMMENT 'A flag to indicate whether content is serialized (1) or not (0).', PRIMARY KEY (`cid`), KEY `expire` (`expire`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Cache table for the rules engine to store configured items.';
It came from: https://www.drupal.org/node/2160645
But when I try to clear my caches now, I get a new error:
PDOException: SQLSTATE[HY000]: General error: 1030 Got error -1 from storage engine: TRUNCATE {cache_rules} ; Array ( ) in cache_clear_all() (line 165 of C:\Users\Mariska\Sites\devdesktop\includes\cache.inc).
I have made a backup and reinstalled Dev Desktop. I replaced the Sites/DevDesktop folder with the one of my backup and placed the database.mysql in the MYSQL folder.
Then I got a cache_field error, restored that with a query and again the cache_rules error. Restored that in the same way as earlier. In both cases PHPMyadmin said that the 'results can back empty' after the query.
And then the same error 1030...
I finally figured it out. It was a storage problem afer all. It was my virus scanner that messed everything up, McAfee. I got a new one now, one that would not take so much space in the performance of my laptop. Let's see.
Thanks,
Mariska.
I think this is a mysql related issue.
This might help you though MySQL Error Code: 1030Got error -1 from storage engine; I've tried to delete data from my database
In brief, your system disks are full or try a table/engine recovery.
Same error, 64 bit MariaDB, Drupal, NOD32 antivirus. Solution: Disable the resident antivirus protection for MySQL folder.