Three sessions, all open in the same HeidiSQL window.
All three to the same MariaDB server.
Each of the three with a different SQL user.
The third session utilizes a user that does NOT have SELECT privileges.
As expected, sessions #1 and #2 work perfectly.
As expected, session #3 has HeidiSQL throwing a dialog error: "SQL Error (1142): SELECT command denied to user '....@localhost' for table '.....'. " It's actually thrown twice every time I click on a table -- which is understandable. Annoying, but understandable.
The bug is that once #3 has failed once, ALL OTHER sessions do something very peculiar. #1 and #2 don't throw any errors (nor should they), and most of everything works perfectly, just like it did in the beginning. However, the table "Basic" tab lists no columns at all. Clicking "Add" to add a column indeed renders an input field, positioned as though there were other rows above it, but there aren't, and while tabbing through the entry fields reveals them one at a time, they are otherwise hidden.
This remains true forever -- hours and days of usage.
Perhaps most interesting is that everything goes back to perfect by simply disconnecting session #3.
This leads me to believe that whatever HeidiSQL process is responsible for populating the "Basic" tab, it is lost waiting for data that never comes, and thus ignores future attempts from other sessions.
For those wondering, my no-select user has alter privileges. It explicitly lacks select privileges to ensure that I don't accidentally use it for normal work.
Three sessions, all open in the same HeidiSQL window.
All three to the same MariaDB server.
Each of the three with a different SQL user.
The third session utilizes a user that does NOT have SELECT privileges.
As expected, sessions #1 and #2 work perfectly.
As expected, session #3 has HeidiSQL throwing a dialog error: "SQL Error (1142): SELECT command denied to user '....@localhost' for table '.....'. " It's actually thrown twice every time I click on a table -- which is understandable. Annoying, but understandable.
The bug is that once #3 has failed once, ALL OTHER sessions do something very peculiar. #1 and #2 don't throw any errors (nor should they), and most of everything works perfectly, just like it did in the beginning. However, the table "Basic" tab lists no columns at all. Clicking "Add" to add a column indeed renders an input field, positioned as though there were other rows above it, but there aren't, and while tabbing through the entry fields reveals them one at a time, they are otherwise hidden.
This remains true forever -- hours and days of usage.
Perhaps most interesting is that everything goes back to perfect by simply disconnecting session #3.
This leads me to believe that whatever HeidiSQL process is responsible for populating the "Basic" tab, it is lost waiting for data that never comes, and thus ignores future attempts from other sessions.
For those wondering, my no-select user has alter privileges. It explicitly lacks select privileges to ensure that I don't accidentally use it for normal work.