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.
Related
I'm scratching my head off, but basically I'm upgrading my RDS instance from MySQL 5.7 to 8.0.
However, it's returning a very odd error during the PrePatchCompatibiity check.
12) Usage of removed functions
Following DB objects make use of functions that have been removed in version 8.0. Please make sure to update them to use supported alternatives before upgrade.
More Information:
https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals
app-website-org-staging.eav_value_point.value_point_value - COLUMN uses removed functions X (consider using ST_X instead), Y (consider using ST_Y instead)
The odd thing here is, I'm NOT using the functions X and Y on this stored generated column. I am ALREADY using ST_X and ST_Y in the generated column function. I was wondering how I can get rid of that error.
What I have tried:
In phpMyAdmin, edit, and save again.
In phpMyAdmin, edit, change the functions to uppercase, and save again.
Used mysqldump to export the table, and verified that indeed I was using ST_X and ST_Y.
Removed the problematic column.
1-3 did not work, 4 worked, but that was not my intention. I want to know the true reason.
Please see my table dump below:
CREATE TABLE `eav_value_point` (
`value_point_id` int(11) UNSIGNED NOT NULL,
`value_point_created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`value_point_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`value_point_modified_by` int(11) UNSIGNED DEFAULT NULL,
`value_point_attribute_id` int(11) UNSIGNED NOT NULL,
`value_point_entity_id` int(11) UNSIGNED NOT NULL,
`value_point_value_real` point NOT NULL,
`value_point_value` varchar(255) COLLATE utf8mb4_unicode_520_ci GENERATED ALWAYS AS (concat(st_x(`value_point_value_real`),',',st_y(`value_point_value_real`))) STORED
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;
If anyone can shed me some light I'd appreciate it! Thanks all in advance!
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
Every time i relog to mysqlworkbench the tables that i have created within my schema have been automatically dropped. This happens after about 2 hours every time. I can't quite figure out if this is some mysql setting or if I have incorrectly configured the database.
I'm accessing the database via java spring-data persistence jpa requests.
sql table entry code:
use storage_app_schema;
CREATE TABLE `StorageItem` (
`DateStored` tinyblob,
`Image` tinyblob,
`Name` varchar(255) DEFAULT NULL,
`ReferenceCode` varchar(255) DEFAULT NULL,
`Size` varchar(255) DEFAULT NULL)
hibernate.hbm2ddl.auto was set to "create". I wasn't aware this dropped existing table. This should be set to "update" - in order to update the existing schema as opposed to overriding it when the session closes.
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 recently noticed that recreating the database for the web application I am working on is taking a lot of time. I had just reinstalled Mysql from Macport...
I am getting really lousy performances, for example :
0.293437004089 seconds for
CREATE TABLE blockip (
id INT(11) NOT NULL AUTO_INCREMENT,
ip VARCHAR(15) NOT NULL DEFAULT '',
username VARCHAR(80) NOT NULL DEFAULT '',
time INT(10) NOT NULL DEFAULT '0', PRIMARY KEY (id) )
DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci TYPE=MyISAM;
On another machine, nearby I get 0.0016529560089111 seconds for the same query.
The trouble seems to be somewhat related to the disk : disk usage goes really high when I start creating the 70 tables in my database.
Any ideas where to start for a clue ?
I saw this myself and found the issue is to do with a file function that is available on OS X but not other operating systems that MySQL chooses to use as it is safer. Check out the last 3 comments on this bug report: http://bugs.mysql.com/bug.php?id=56550.
It details adding a directive to your my.cnf file that will disable using the different function and dramatically speeds up all file based actions in MySQL on OS X. So, you can fix this quickly by adding the following to your my.cnf file in the [mysqld] block. It’s probably best not to do this in production, but who actually uses OS X as a production web server anyway?
skip-sync-frm=OFF
I saw my unit test schema creation come down from 16 seconds to 5 making it a clear winner for me.