dbForge Studio for MySQL: Bugs (62 ideas) – Customer Feedback for Devart

I suggest you...

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

When an admin closes an idea you've voted on, you'll get your votes back from that idea.
You can remove your votes from an open idea you support.
To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".

Enter a new feature, request a bugfix, or ask a question

(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

Fix error

dbForge MySQL 10.1.158:

When a stored procedure is very large, the reference to the database's created functions is lost and an error occurs. I still think that the best version they have released, by far, is 9.0.567; it has the fewest errors and is much more stable than the subsequent versions. I'm sharing the error that appears:

=========================

Exception Information

Place: 2
ExceptionId: 9ac1d2da-2b6b-417c-ab02-5046d2ba261e
Message: Referencia a objeto no establecida como instancia de un objeto.
Source: Devart.DbForge.DbEditors
TargetSite: Void Brgc(Devart.ComponentModel.Runtime.Severity)
HelpLink:
Type: System.NullReferenceException
Stack:
en Devart.DbForge.DbObjects.DbObjectEditor.Brgc(Severity )
en Devart.DbForge.DbObjectDocument.qrJN()
en Devart.DbForge.DbObjectDocument.irJP()
en System.Windows.Forms.Timer.OnTick(EventArgs e)
en System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
en System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

dbForge MySQL 10.1.158:

When a stored procedure is very large, the reference to the database's created functions is lost and an error occurs. I still think that the best version they have released, by far, is 9.0.567; it has the fewest errors and is much more stable than the subsequent versions. I'm sharing the error that appears:

=========================

Exception Information

Place: 2
ExceptionId: 9ac1d2da-2b6b-417c-ab02-5046d2ba261e
Message: Referencia a objeto no establecida como instancia de un objeto.
Source: Devart.DbForge.DbEditors
TargetSite: Void Brgc(Devart.ComponentModel.Runtime.Severity)
HelpLink:
Type: System.NullReferenceException
Stack:
en Devart.DbForge.DbObjects.DbObjectEditor.Brgc(Severity )
en Devart.DbForge.DbObjectDocument.qrJN()
en Devart.DbForge.DbObjectDocument.irJP()
en System.Windows.Forms.Timer.OnTick(EventArgs e)
en System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
en System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd,…

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 1 comment · Bugs · Delete… · Admin →
Fix Schema Comparison issue for Stored Functions that return text values

When comparing Stored Functions that return text values using Schema Comparison, it should display the correct character set and collation as reported by information_schema.routines.

Currently, when comparing a MySQL 5.7 source host to a MySQL 8.0 replica of that source, Schema Comparison incorrectly reports the character set and collation of the RETURN value of Stored Functions that return text values on the MySQL 8.0 host. This leads to false positives in the reported list of schema differences.

For example, actual RETURNS value:
RETURNS VARCHAR(80) CHARSET utf8mb3 COLLATE utf8mb3generalci

Reported RETURNS value (incorrect):
RETURNS VARCHAR(80) CHARSET utf8mb4 COLLATE utf8mb40900ai_ci

Curiously, if you generate the changeset to update the MySQL 8.0 host, it uses the correct character set and collation.

When comparing Stored Functions that return text values using Schema Comparison, it should display the correct character set and collation as reported by information_schema.routines.

Currently, when comparing a MySQL 5.7 source host to a MySQL 8.0 replica of that source, Schema Comparison incorrectly reports the character set and collation of the RETURN value of Stored Functions that return text values on the MySQL 8.0 host. This leads to false positives in the reported list of schema differences.

For example, actual RETURNS value:
RETURNS VARCHAR(80) CHARSET utf8mb3 COLLATE utf8mb3generalci

Reported RETURNS value (incorrect):
RETURNS VARCHAR(80) CHARSET utf8mb4 COLLATE utf8mb4…

2 votes

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 2 comments · Bugs · Delete… · Admin →
copy and paste

copy anda paste from view data and excel not work

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 2 comments · Bugs · Delete… · Admin →
9.2.105 Bug -- Cannot connect (SSL) to AWS Aurora MySQL

Using identical configuration and credentials, v9.2.34 (and previous versions) connects to my AWS Aurora MySQL instance over SSL. However, the v9.2.105 update does NOT connect. It returns a dialog stating "SSL connection error (2026): The server hello message uses a protocol that was not recognized."

I tried many configurations, but none worked. Uninstalled and downgraded, worked on first try. Updated to latest and repeated test, same failure.

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 2 comments · Bugs · Delete… · Admin →
Separate DEFINER and SQL SECURITY in exclude backup options

It only makes sense to combine these two options when SQL SECURITY is set to DEFINER. In the other case (INVOKER) it will cause a problem if the DEFINER is specified when restoring the database to a different environment - user will not exist or will not have the right privileges. "Exclude DEFINER" and "Exclude SQL SECURITY" should be two separate options when backing up a database.

3 votes

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 2 comments · Bugs · Delete… · Admin →
Code for CREATE TABLE with MariaDb "system versioning" is not generated correctly.

On a table with system versioning, from context menu I select:
Generate script as > CREATE > To new SQL window.
And the output does not include SYSTEM VERSIONING data at all.
When I run SHOW CREATE TABLE tablename - I get correct information.

The same with "Edit table"
(In general it would be nice to set, if "Generate script" uses dbForge engine, or from database "SHOW CREATE TABLE", because output sometimes is drastically different)

2 votes

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 1 comment · Bugs · Delete… · Admin →
Code for CREATE TABLE with MariaDb "system versioning" is not generated correctly.

On a table with system versioning, from context menu I select:
Generate script as > CREATE > To new SQL window.
And the output does not include SYSTEM VERSIONING data at all.
When I run SHOW CREATE TABLE tablename - I get correct information.

The same with "Edit table"
(In general it would be nice to set, if "Generate script" uses dbForge engine, or from database "SHOW CREATE TABLE", because output sometimes is drastically different)

0 votes

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 1 comment · Bugs · Delete… · Admin →
MariaDB Spider Engine Comment Field Get Trimmed in generated Script when modified

We would store the connection information in comment, there is no problem when we first create the table in SQL script, but once we want to modify and generate the script from dbForge Studio, comment field get trimmed and stored information is missing

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 0 comments · Bugs · Delete… · Admin →
copy databaes not works when we try copy from ndbd to innodb cluster

copy databaes not works when we try copy from ndbd to innodb cluster.
if exist options skip engine it will be works

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

0 comments · Bugs · Delete… · Admin →

completed · AdminDevart (_, Devart) responded

Now, there is an option to ignore an engine.
Mysql database copy from innodb to ndbcluster is notpossible

Mysql database copy from innodb to ndbcluster is not possible becuase when we copy we can't chose without engine set. In result on cluster each database use same engine as source (not clustered)

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

0 comments · Bugs · Delete… · Admin →

completed · AdminDevart (_, Devart) responded

An option to ignore engines is added.
AUTO_INCREMENT

When I insert new record to table using table editor, ( id int(11) UNSIGNED NOT NULL AUTO_INCREMENT ) new field doesn't give the proper ID number. Seems like the editor can't find next free ID on auto increment field

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 1 comment · Bugs · Delete… · Admin →
Script generation auto_increment bug

When backing up a database or creating CREATE script from a table, the auto_increment attribute is not set on a column which is not defined as a primary key.

eg.

CREATE TABLE wpquestionsformelement (
elementid int(11) NOT NULL AUTOINCREMENT,
formid int(11) NOT NULL,
elementorder int(11) NOT NULL,
elementtypecode varchar(50) NOT NULL,
elementparams varchar(3000) DEFAULT NULL,
questionid int(11) DEFAULT NULL,
attachmentid int(11) DEFAULT NULL,
mandatory bit(1) NOT NULL DEFAULT b'0',
deletedflag tinyint(1) NOT NULL DEFAULT 0,
PRIMARY KEY (formid, elementorder),
INDEX idxwpquestionsformelementelementid (elementid)
)
ENGINE = INNODB,
AUTOINCREMENT = 262150,
AVGROWLENGTH = 76,
CHARACTER SET latin1,
COLLATE latin1swedishci;

When creating the script dbForge omits the auto_increment attribute as follows:

CREATE TABLE wpquestionsformelement (
elementid int(11) NOT NULL,
formid int(11) NOT NULL,
elementorder int(11) NOT NULL,
elementtypecode varchar(50) NOT NULL,
elementparams varchar(3000) DEFAULT NULL,
questionid int(11) DEFAULT NULL,
attachmentid int(11) DEFAULT NULL,
mandatory bit(1) NOT NULL DEFAULT b'0',
deletedflag tinyint(1) NOT NULL DEFAULT 0,
PRIMARY KEY (formid, elementorder)
)
ENGINE = INNODB,
AUTOINCREMENT = 262150,
AVGROWLENGTH = 76,
CHARACTER SET latin1,
COLLATE latin1swedishci;

--

-- Create index idx_wp_questions_form_element_elementid on table wp_questions_form_element

ALTER TABLE wpquestionsformelement
ADD INDEX idxwpquestionsformelementelementid (elementid);

This happens for all entities which have autoincrement columns defined in informationschema.columns with a COLUMN_KEY = MUL

When backing up a database or creating CREATE script from a table, the auto_increment attribute is not set on a column which is not defined as a primary key.

eg.

CREATE TABLE wpquestionsformelement (
elementid int(11) NOT NULL AUTOINCREMENT,
formid int(11) NOT NULL,
elementorder int(11) NOT NULL,
elementtypecode varchar(50) NOT NULL,
elementparams varchar(3000) DEFAULT NULL,
questionid int(11) DEFAULT NULL,
attachmentid int(11) DEFAULT NULL,
mandatory bit(1) NOT NULL DEFAULT b'0',
deletedflag tinyint(1) NOT NULL DEFAULT 0,
PRIMARY KEY (formid, elementorder),
INDEX idxwpquestionsformelementelementid (elementid)
)
ENGINE =…

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 0 comments · Bugs · Delete… · Admin →
utf8mb4 support

The databse charset set to "utf8mb4" and the collation set to "utf8mb4generalci". The table set as same as database, this field same as database. But when run query statement, all the chinese character was unreadable, the comment of field does too. For the comment of field, the correct string should be "地区Id", when I edit the table, he character look such as "鍦板尯Id". The other mysql studio works fine, such as MySql Workbench, Navicat.

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 2 comments · Bugs · Delete… · Admin →
Fix data compare by text key

Beginning with dbForge Studio of MySQL 7.3 (possibly earlier), and continuing into the recently released 7.4.201, I am seeing some incorrect results when using the data comparison feature.

Specifically, it seems to happen when I compare data based on a textual key column rather than the integer-based primary key. Here is an simple example that will produce incorrect results with 7.4.201:

-- ###########################################
-- Server 1

CREATE TABLE test (
id INT(10) UNSIGNED NOT NULL AUTOINCREMENT,
key VARCHAR(255) NOT NULL,
value VARCHAR(80) NOT NULL,
PRIMARY KEY (id),
UNIQUE INDEX uniquekey (key)
)
ENGINE = INNODB,
CHARACTER SET utf8,
COLLATE utf8generalci;

INSERT INTO test(id, key, value) VALUES
(1, 'PROBLEM12', 'Not Only in Source, Not PROBLEM123456789'),
(2, 'PROBLEM123456789', 'Not Only in Target, Not Different'),
(3, 'NEW1', 'NEW1name'),
(4, 'NEW2', 'NEW2name');

-- ###########################################
-- Server 2

CREATE TABLE test (
id INT(10) UNSIGNED NOT NULL AUTOINCREMENT,
key VARCHAR(255) NOT NULL,
value VARCHAR(80) NOT NULL,
PRIMARY KEY (id),
UNIQUE INDEX uniquekey (key)
)
ENGINE = INNODB,
CHARACTER SET utf8,
COLLATE utf8generalci;

INSERT INTO test(id, key, value) VALUES
(1, 'PROBLEM12', 'Not Only in Source, Not PROBLEM123456789'),
(2, 'PROBLEM123456789', 'Not Only in Target, Not Different');

After creating the table and data on two servers, run the "New Data Comparison" tool and select the Test table. Under the Column Mapping dialog:

id: (uncheck key, and compare, leaving only sync checked)
key: (check key, leaving compare and sync checked)
value: (no change, leave compare and sync checked)

Run the compare.

Under the "Only in Source" results, it will incorrectly include the record with key=PROBLEM12. Under Different Records, it will incorrectly display record id 1 as if it had the key belonging to record id 2. Under "Only in Target", it will incorrectly include the record with key=PROBLEM_123456789.

Naturally, this is very concerning, as it could lead to data corruption when deploying changes from one server to another. Also, the synchronization script contains results which are obviously incorrect and will produce and error (given the unique constraint on the key column).

--

-- Deleting data from table test

DELETE FROM test WHERE key = 'PROBLEM_123456789';

--

-- Updating data of table test

UPDATE test SET id = 2, value = 'Not Only in Target, Not Different' WHERE key = 'PROBLEM_123456789';

--

-- Inserting data into table test

INSERT INTO test(key, id, value) VALUES
('NEW1', 3, 'NEW1name'),
('NEW2', 4, 'NEW2name'),
('PROBLEM12', 1, 'Not Only in Source, Not PROBLEM_123456789');

This will cause the UPDATE to not have any records to update, and then throw a unique key constraint error when attempting to insert a duplicate key for "PROBLEM12".

Beginning with dbForge Studio of MySQL 7.3 (possibly earlier), and continuing into the recently released 7.4.201, I am seeing some incorrect results when using the data comparison feature.

Specifically, it seems to happen when I compare data based on a textual key column rather than the integer-based primary key. Here is an simple example that will produce incorrect results with 7.4.201:

-- ###########################################
-- Server 1

CREATE TABLE test (
id INT(10) UNSIGNED NOT NULL AUTOINCREMENT,
key VARCHAR(255) NOT NULL,
value VARCHAR(80) NOT NULL,
PRIMARY KEY (id),
UNIQUE INDEX uniquekey (key)
)
ENGINE = INNODB,
CHARACTER…

3 votes

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 0 comments · Bugs · Delete… · Admin →
Fix false-positive syntax error detection when using UNION

I recently upgraded to dbForge 7.3 and discovered that the SQL syntax highlighter is incorrectly highlighting valid SQL (per MySQL 5.6) as if there is an error. Example SQL is below.

The effect is that the word "UNION" in the SELECT statement will display the red error underline (hover text: 'Identifier' expected) and the closing parenthesis will be similarly highlighted (hover text: Unexpected symbol ')'). If you run the query, the error highlighting will disappear until the SQL is edited, at which point it will immediately return.

-- SQL syntax highlighter bug in dbForge for MySQL 7.3.137

DROP TEMPORARY TABLE IF EXISTS a;
DROP TEMPORARY TABLE IF EXISTS b;

CREATE TEMPORARY TABLE a (
id INT(10) UNSIGNED NOT NULL AUTOINCREMENT,
PRIMARY KEY (id)
)
CHARACTER SET utf8
COLLATE utf8general_ci
;

CREATE TEMPORARY TABLE b (
id INT(10) UNSIGNED NOT NULL AUTOINCREMENT,
PRIMARY KEY (id)
)
CHARACTER SET utf8
COLLATE utf8general_ci
;

INSERT INTO a (id) VALUES(1),(2),(3);
INSERT INTO b (id) VALUES(1),(2),(3);

SELECT *
FROM (
(
SELECT 'A'
)
UNION (
SELECT 'B'
FROM a
JOIN b ON a.id=b.id
)
) AS foo
;

DROP TEMPORARY TABLE IF EXISTS a;
DROP TEMPORARY TABLE IF EXISTS b;

I recently upgraded to dbForge 7.3 and discovered that the SQL syntax highlighter is incorrectly highlighting valid SQL (per MySQL 5.6) as if there is an error. Example SQL is below.

The effect is that the word "UNION" in the SELECT statement will display the red error underline (hover text: 'Identifier' expected) and the closing parenthesis will be similarly highlighted (hover text: Unexpected symbol ')'). If you run the query, the error highlighting will disappear until the SQL is edited, at which point it will immediately return.

-- SQL syntax highlighter bug in dbForge for MySQL 7.3.137

DROP TEMPORARY TABLE…

0 votes

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 1 comment · Bugs · Delete… · Admin →
Crashed automatically

During a long time runing and I havn't do any operation, the dbForge Studio for MySQL will crashed by itsell.

I see the windows event log like below, any solution?

Faulting application name: dbforgemysql.exe, version: 7.3.137.0, time stamp: 0x5a5750d3
Faulting module name: ucrtbase.dll, version: 10.0.15063.674, time stamp: 0x8ac9f9d4
Exception code: 0xc0000409
Fault offset: 0x000000000007350e
Faulting process id: 0x26fc
Faulting application start time: 0x01d398c7e6228539
Faulting application path: C:\Program Files\Devart\dbForge Studio Express for MySQL\dbforgemysql.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: dc61c8e8-1ed4-44d0-8ac0-57011fb3f67a
Faulting package full name:
Faulting package-relative application ID:

2 votes

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 4 comments · Bugs · Delete… · Admin →
bugfix

After a few hours open, either maximized or minimized, it gets frozen, I cannot click in any button. It is like if an invisible modal button is blocking the input. This is the latest version 7.3.131. please let me know how can I help you find the issue

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 1 comment · Bugs · Delete… · Admin →
common table expressions

dbForge Studio Express for MySql Version - 7.2.78

MariaDB 10.2.10

Cannot create Procedure with Common Table Expressions
The syntax checker cannot handle WITH clause, so even Procedures that work cannot be edited.

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 0 comments · Bugs · Delete… · Admin →
mariadb

I have two mysql server. MariaDB 10.2 and Mysql 5.5.23
When i make structure comparation i have such differences with default null fields:
In MariaDB 10.2:
guiname VARCHAR(200) DEFAULT 'NULL',
description VARCHAR(2000) DEFAULT 'NULL',
In Mysql:
guiname VARCHAR(200) DEFAULT NULL,
description VARCHAR(2000) DEFAULT NULL,

And after sync these differences are remained

7 votes

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 1 comment · Bugs · Delete… · Admin →
The "default" project build sequence is incorrect.

The "default" project build sequence is incorrect. dbForge Studio try to build a prolect as follows: Views, Procedures, Tables, Functions. https://www.screencast.com/t/kTg7D6sJR This leads errors at deployment stage since MySql cannot create a view if corresponding table doesn't exist. I have to change build sequence each time to correct this.

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

completed · 1 comment · Bugs · Delete… · Admin →

← Previous 1 2 3 4 Next →

Don't see your idea?

dbForge Studio for MySQL

Categories

I suggest you...

There are two ways to get more votes:

We're glad you're here

Exception Information

Exception Information

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

-- Create index idx_wp_questions_form_element_elementid on table wp_questions_form_element

We're glad you're here

We're glad you're here

-- Deleting data from table test

-- Updating data of table test

-- Inserting data into table test

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

We're glad you're here

-- Create index `idx_wp_questions_form_element_elementid` on table `wp_questions_form_element`