Search found 44 matches

by tfrancois
Tue 11 Oct 2022 11:17
Forum: dbForge for MySQL
Topic: [9.1.8]: BUG: Strange error condition in query window for JSON_TABLE.
Replies: 5
Views: 25193

Re: [9.1.8]: BUG: Strange error condition in query window for JSON_TABLE.

Hello,

Yes I can absolutely confirm that the issue persists even with current version 9.1.21 of dbForge.

Here is an INTERESTING tidbit - the error goes away when I alter the SELECT statement as follows:

Code: Select all

SELECT GROUP_CONCAT(id) FROM JSON_TABLE(@json, '$[*]' COLUMNS (id INT UNSIGNED PATH '$')) `ids` GROUP BY id;
This forces the query to return multiple rows by using the GROUP_CONCAT function combined with GROUP BY clause - effectively returning the same multiple rows as the original query. But this is a workaround - the error should not be present because the original query is valid.

Thank you.
by tfrancois
Wed 31 Aug 2022 23:21
Forum: dbForge for MySQL
Topic: connect via system DSN?
Replies: 5
Views: 60727

Re: connect via system DSN?

Not sure if this is helpful to you, but did you not explore this:

From Devart:
https://www.devart.com/odbc/mysql/compatibility.html

From MySQL: (8.0 version but I believe there are versions for MySQL 5.7 as well)
https://dev.mysql.com/downloads/connector/odbc/

Respectfully, Google is your friend.
by tfrancois
Wed 17 Aug 2022 11:36
Forum: dbForge for MySQL
Topic: URGENT: [Enterprise 9.0.791] ALL rows updated on a table when only ONE row modified in editor!
Replies: 14
Views: 697769

Re: URGENT: [Enterprise 9.0.791] ALL rows updated on a table when only ONE row modified in editor!

Thank you for your reply. I can respectfully confirm that issue is still NOT fixed.

I confirmed this by performing the exact same test as in my original post above. I created the table with the SQL provided above. I then populated it with the test records by running the accompanying INSERT statement above.

Then, I performed an edit on one of the last name fields and hit Refresh. Issue APPEARS resolved. Until I perform a second update on a different row, hit Refresh and all the rows are updated with the newly modified last name.

Image

To repeat, it appears to be fixed on first update but same error occurs on a second update in a different row! Thank you.
by tfrancois
Wed 17 Aug 2022 11:26
Forum: dbForge for MySQL
Topic: [9.1.8]: BUG: Strange error condition in query window for JSON_TABLE.
Replies: 5
Views: 25193

Re: [9.1.8]: BUG: Strange error condition in query window for JSON_TABLE.

The server version is Amazon Aurora v3 MySQL - which is wire equivalent to MySQL 8.0.23.
by tfrancois
Sun 14 Aug 2022 17:44
Forum: dbForge for MySQL
Topic: [9.1.8]: BUG: Strange error condition in query window for JSON_TABLE.
Replies: 5
Views: 25193

[9.1.8]: BUG: Strange error condition in query window for JSON_TABLE.

For some strange reason, the following valid and correct JSON_TABLE command generates an error when executing the following statement in a new query window or stored procedure.

Code: Select all

SET @json = CONVERT('[1095, 1106, 1193, 1288, 1357, 1385, 1390]', JSON);
SELECT ids.* FROM JSON_TABLE(@json, '$[*]' COLUMNS (id INT UNSIGNED PATH '$')) `ids`;
The command returns correct results in the rows section below, but still generates a SQL error as shown:
Image

The exact SQL error text that occurs:
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 '.`json_table` WHERE non_unique = 0' at line 1
Please fix this error - it took me forever to realize there was no issue with the syntax and it is a weird error that only occurs in dbForge. Thank you.
by tfrancois
Fri 12 Aug 2022 19:44
Forum: dbForge for MySQL
Topic: URGENT: [Enterprise 9.0.791] ALL rows updated on a table when only ONE row modified in editor!
Replies: 14
Views: 697769

Re: URGENT: [Enterprise 9.0.791] ALL rows updated on a table when only ONE row modified in editor!

Still disappointed to report that with the release of version v.9.1.8, this STILL continues to be an issue. When are we going to resolve this MAJOR issue please Devart?
by tfrancois
Fri 12 Aug 2022 19:42
Forum: dbForge for MySQL
Topic: [9.0.791]: Support for JSON_VALUE needed in table definition and stored procs/functions
Replies: 5
Views: 13476

Re: [9.0.791]: Support for JSON_VALUE needed in table definition and stored procs/functions

I can happily confirmed this issue has been resolved with the release of v9.1.8. Thank you!
by tfrancois
Sat 21 May 2022 09:55
Forum: dbForge for MySQL
Topic: URGENT: [Enterprise 9.0.791] ALL rows updated on a table when only ONE row modified in editor!
Replies: 14
Views: 697769

Re: URGENT: [Enterprise 9.0.791] ALL rows updated on a table when only ONE row modified in editor!

Hello again @dzhanhira and Support Team,

Based on your information below, I did some digging and would like to offer some guidance or suggestion on how to resolve this issue in dbForge.
dzhanhira wrote: Thu 19 May 2022 10:03
When executing the Retrieve Data command, we send a SELECT * FROM <table_name> query to the server;

You have assigned the INVISIBLE attribute to one of the columns. This means that this column (with data) will not appear in the list of columns in the result of a SELECT * FROM <table_name> query. In this case, the INVISIBLE column is part of the PRIMARY KEY. As a result, the returned data set does not contain KEY columns that allow you to safely perform data editing operations.
Here is a stored procedure that runs and retrieves all data from a table, including invisible columns. The caveat to this method is that it requires the use of a prepared statement in order to access the information_schema table directly - so I am not sure if that is something the IDE can do when user selects to view table data:

Code: Select all

CREATE PROCEDURE `get_data`(IN v_table VARCHAR(255))
    READS SQL DATA
BEGIN
  DECLARE v_query VARCHAR(5000);
	
  SET SESSION group_concat_max_len = 1024000;
  SELECT CONCAT('SELECT ', GROUP_CONCAT(distinct c.COLUMN_NAME ORDER BY c.ORDINAL_POSITION) , ' FROM ',v_table, ' LIMIT 1000;') INTO v_query from information_schema.`COLUMNS` c where c.table_name = v_table and table_schema=DATABASE();

  SET @sql = v_query;
  PREPARE stmt FROM @sql;
  EXECUTE stmt;
  DEALLOCATE PREPARE stmt;

END
FYI, notice the limit 1000 I added to mimick the default behavior of the IDE today. The thought being additional SP parameters could be passed in to modify the LIMIT clause as needed.

The beauty of this approach is that the column visibility does not affect the output. Now, to determine which columns are marked as INVISIBLE by the table author, you can check the EXTRA column value in the information_schema table (as shown below) and perhaps do something visual in the IDE to let the user know which columns are invisible as opposed to not.

From MySQL documentation:
https://dev.mysql.com/doc/refman/8.0/en ... n-metadata

Code: Select all

mysql> SELECT TABLE_NAME, COLUMN_NAME, EXTRA
       FROM INFORMATION_SCHEMA.COLUMNS
       WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 't1';
+------------+-------------+-----------+
| TABLE_NAME | COLUMN_NAME | EXTRA     |
+------------+-------------+-----------+
| t1         | i           |           |
| t1         | j           |           |
| t1         | k           | INVISIBLE |
+------------+-------------+-----------+
I'm hoping a mixture of these techniques would allow the developers to add support for Invisible columns (albeit it appears with some work) in a future release soon. As there is no way of knowing who would be making use of this important new feature in MySQL 8, I'd assume the sooner the better for safety reasons. Thank you again as always.
by tfrancois
Fri 20 May 2022 14:59
Forum: dbForge for MySQL
Topic: URGENT: [Enterprise 9.0.791] ALL rows updated on a table when only ONE row modified in editor!
Replies: 14
Views: 697769

Re: URGENT: [Enterprise 9.0.791] ALL rows updated on a table when only ONE row modified in editor!

Dear @dzhanhira,

My absolute sincerest apologies for seemingly being so insensitive to the plight of the people in Ukraine, and not knowing or fully realizing how that affected the Devart team and their families.

I want you to know that the vast majority of the American people stand with Ukraine unequivocally and without exception. We as a free people sometimes take fore granted our liberties and freedoms and seem to look the other way when freedom-loving people elsewhere in our world are suffering. Unfortunately, most average citizens are not able to impact the kind of change to bring this pain to an end directly, but at the very very least, we can express our solidarity to our human brethren and pray to our higher power that the tragedies we are witnessing come to an end as soon as possible. I apologize sincerely for having been totally unaware of how this war has been impacting Devart and appreciate all of your hard work and efforts to continue to deliver on your EXCELLENT products - the only one(s) I use - and will continue to use - in your market space. I will continue to hold Ukraine, including more specifically all those at Devart, in my thoughts and prayers and urge you and your families to please try to stay safe and out of harms way as your first and most urgent priority always.

Thank you for your reply and hope we can find a fix that would both enable the ability to set key columns invisible while being able to make changes to data without fear of the issue discussed herein. I'm sure at some point a solution can be found but understand now that there are bigger priorities at this time. Long live Ukraine!
by tfrancois
Wed 18 May 2022 16:48
Forum: dbForge for MySQL
Topic: URGENT: [Enterprise 9.0.791] ALL rows updated on a table when only ONE row modified in editor!
Replies: 14
Views: 697769

Re: URGENT: [Enterprise 9.0.791] ALL rows updated on a table when only ONE row modified in editor!

Hello @dzhanhira and support team,

Respectfully, there have been 2 updates to dbForge since I reported this major issue and after applying both updates, the issue I mentioned here has still not been resolved. This is a major issue that I truly have to believe requires more urgency and supercede all other bug fixes/enhancements, no? I'm disappointed that it appears that it doesn't seem as if its being addressed as quickly as I thought it would be, given the seriousness in the nature of the bug we've identified that clearly risks data integrity. Any timeline on a release for this fix please? I urge, again respectfully, that there should be no higher priority given the damage this bug can do on such a massive scale. Please advise. Thank you.
by tfrancois
Fri 13 May 2022 13:32
Forum: dbForge for MySQL
Topic: [9.0.897]: BUG: Incorrect ordering of parameters in Edit Parameters dialog box on repeat executions
Replies: 2
Views: 11949

[9.0.897]: BUG: Incorrect ordering of parameters in Edit Parameters dialog box on repeat executions

In the latest release, I found a bug that just appeared that I haven't noticed appeared in previous builds. When executing a STORED FUNCTION from a database using the IDE and entering the function parameters in the Edit Parameters dialog box that appears, the arguments are entered in the requested order and the function runs fine the first time.

On subsequent calls to the same function immediately thereafter, the same dialog box reappears but the parameters that were previously entered have each moved down 1 in the order sequence while the first parameter is skipped. This behavior does not seem to occur for stored procedures, only for stored functions.

Again, this issue seems to have just appeared in the latest build. Please kindly look into and resolve.
by tfrancois
Fri 13 May 2022 04:42
Forum: dbForge for MySQL
Topic: [9.0.791]: Support for JSON_VALUE needed in table definition and stored procs/functions
Replies: 5
Views: 13476

[9.0.791]: Support for JSON_VALUE needed in table definition and stored procs/functions

Hello Devart Support,

It appears that dbForge does not currently fully support the JSON_VALUE() function syntax which includes the ability to utilize the RETURNING type arguments (allow CASTing of returned value to a specific data type). When attempting to create a generated column in the Table Editor or using the function and syntax in a stored function or procedure, neither allows the code to be saved because the interpreter views it as an error. This is valuable new function in that eliminates the need to write more verbose SQL code for type casting.

For more information on the new function and syntax:
https://dev.mysql.com/doc/refman/8.0/en ... json-value

Support was added by the language for this function as of MySQL 8.0.21.

Code: Select all

mysql> SELECT JSON_VALUE('{"item": "shoes", "price": "49.95"}', '$.price' RETURNING DECIMAL(4,2)) AS price;
+-------+
| price |
+-------+
| 49.95 |
+-------+
Respectfully, can we please add support for this as soon as feasibly possible. Thank you as always.
by tfrancois
Thu 12 May 2022 09:30
Forum: dbForge for MySQL
Topic: [9.0.791] Feature Request: Defining ENUM columns in Table Editor needs refinement/bug fixes
Replies: 0
Views: 11432

[9.0.791] Feature Request: Defining ENUM columns in Table Editor needs refinement/bug fixes

When adding a new ENUM column in create/edit mode in the Table Editor, the editor never behaves consistently or intuitively. When first selecting the ENUM column type on a new column, the user is immediately presented with an error with a red X that prevents completing the definition unless enum values are entered in the narrow space provided in the Data Type column in a very specific fashion: single-quoted, comma-separated values enclosed in parenthesis, all in the very narrow space available to do so in the Data Type column in the Table Editor.

The frustration here is that there is a Values property in the Column properties (right pane) of the table editor where properly defined enums appear (eventually) when the values are entered exactly as required (trying to perform any other action in the Table Editor window is disallowed otherwise). Why not allow the user to simply select ENUM data type and then allow the enum values to be entered in the Values dialog box mentioned earlier? This way, the IDE can properly format the ENUM column definition consistently upon saving of the table definition.

Secondly, when adding or modifying values in the popup dialog editor that appears for the Values property for ENUM columns, if the strings entered are not specified with double-quotes on first entry, validation errors occur.

Entering in values with single-quotes or no-quotes is not accepted - which is confusing - because when modifying an existing ENUM column with pre-existing values in the Values dialog, no quotes are required or are visible when the list is pre-populated with existing values. It appears that this dialog exhibits 2 different behaviors: one for ENUM columns that were previously defined earlier and the other mode (with different entry requirements) when first creating an enum column prior to saving.

It would be so much more helpful to have consistent behavior at all times for ENUM columns. Please advise and thank you.