Somehow I've changed a setting or something so that now when I export the database as a forward engineering script it adds an empty COMMENT '' string after ever column in every table. Has anyone experienced this and how can I make it stop?
I'ved carefully checked all settings/preferences I can find. I've uninstalled and reinstalled. I've deleted the entire MySQL folder under User/AppData/Roaming I don't know what else to try. My fellow developers (I've had 2 try) do not experience the rogue comments at the end. Yes I am using the latest database.mwb file freshly checked out from SVN then same as everyone else.
Even though it's harmless, it still causes problems because then as Gold Copy changes are made the to database schema it'll look like I was the last one to edit every column of every table which will not work.
Here is a sample of some of the columns:
`required` TINYINT NULL DEFAULT NULL COMMENT '',
`created_timestamp` TIMESTAMP NULL DEFAULT NULL COMMENT '',
`created_by_userid` CHAR(3) NULL DEFAULT NULL COMMENT '',
`modified_timestamp` TIMESTAMP NULL DEFAULT NULL COMMENT '',
How can I get rid of the COMMENT ''?
Ok. Apparently it's caused by the latest version of the MySQL workbench. 6.3. I had tried a much earlier version of the workbench and while it hadn't spit out the COMMENT it had spit out other weird things, but I didn't try nearer to latest version until just barely and apparently that solves it. So MySQL workbench 6.2.5 correctly spits out no comments when there aren't any to be had.
Related
I can't seem to figure out an underlying datatype issue (at least I think it is a datatype issue). Obviously writing here as I can't seem to put my finger on what is going wrong
Some background:
We have been trying to upgrade from mysql 5.7 to mysql 8.0.22 and I am tasked in checking database issues regarding inconsistencies. We fixed a timestamp datatype issue earlier in making sure both the times were in the same timezones and that seems to be in check. However, on mysql 8.0.22 I am facing a weird issue when grouping on this timestamp. Here is a small sample of the output that is eluding me:
The query essentially goes like
select year(date)
, month(date)
, *aggregation(a)*
, *aggregation(b)*
etc.
from blabla
join blabla
group by 1,2
It is just not making the month unique. I have a work around by using dateformat function however, I am just curious what might be causing this issue. This same query is working fine on my 5.7 db. I have checked that both databases are exact replicas in multiple ways. Any insight would be greatly appreciated.
Thank you!
edit As people wanted exact context as to what is going on. Here is a simplified query from the same table that shows the problem at hand.
edit no 2 I am adding the information schema and 10 rows for visibility of what the data looks like.
sample data:
schema:
Let me know if there is anything else you need to help me solve this. Apologies for the incomplete information. This part of database management/engineering or technical know how eludes me.
show create table results :
CREATE TABLE `order_status_history` (
`id` int NOT NULL AUTO_INCREMENT,
`order_id` int NOT NULL,
`admin_user_id` int NOT NULL,
`admin_user_name` varchar(255) NOT NULL,
`order_status` varchar(255) NOT NULL,
`date_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`o_type` enum('R','C','D') DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `indx_order_id` (`order_id`),
KEY `indx_order_status` (`order_status`),
KEY `indx_o_type` (`o_type`)
) ENGINE=InnoDB AUTO_INCREMENT=2375978 DEFAULT CHARSET=latin1
According to the MySQL 8.0 docs, the GETMONTH() function works with a date, not a timestamp. So you would need to do something like GETMONTH(FROM_UNIXTIME(date_update)) for your query to return expected results. What's interesting is that you said this was working in MySQL 5.7, but the docs for that function are identical to that found for 8.0. The one difference that your two installations might have is with the lc_time_names system variable, but this is just speculation.
A similar question was asked on this site about eight years ago, and the accepted answer is the same as I outlined above. 🤔
Let's say I have a table 'day_attribute_type'
id bigint(20) AI PK
code varchar(255)
persist_date bigint(20)
update_date bigint(20)
active bit(1)
max int(11)
min int(11)
name varchar(255)
If I would add a new row into the Result Grid and press the Apply button, I would get the following query:
INSERT INTO `tl2`.`day_attribute_type` (`persist_date`, `update_date`, `active`, `max`, `min`, `name`)
VALUES ('1', '2', b'1', b'12', b'12', b'text');
It looks like Workbench puts 'b' not only before the bit field, but also before some other fields. It's really annoying to post-edit the query and remove their buggy things.
MySQL WorkBench 8.0.16 x64, Windows 10
MYSQL Community Server 8.8.12
I've updated MySQL Workbench for a year and this nasty bug continued to appear... I've even reinstalled my Windows.
It looks like nobody is going to fix it. It is mentioned here. Please, can somebody try to reproduce this bug on Linux/Max and confirm either you have it or not.
Tried this out myself (MySQL Workbench 8.0.19 on Windows) and saw the same results - agree it's pretty annoying.
As the issue hasn't been fixed in 4+ years I'd be tempted to use another MySQL GUI client for this purpose such as HeidiSQL, ToadSQL or DBeaver. Credit to JW-Munich for suggesting the last one in the comments.
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.
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.