Two ideas for HeidiSQL
HeidiSQL is great, but it has two big issues that from my point of view. I think they are important, maybe others will agree...
I'm not sure if that's the right technical term. If I leave HeidiSQL (5 0 0 3042) for an hour or so, when I come back it's unresponsive for about 25 seconds, and then quickly reconnects and retrieves the database information.
AT first I thought perhaps the delay is something unique on my server, but version heidisql.r2688 does not feature this delay (and I use this in preference to the latest one because the delay is so long I forget what I wanted to do).
Query Result Update
Let's say I want to update the seq field in the following set of data to 10, 20, 30 etc.
Select id, field1, field2, field3, seq
where field1 = 1
and field2 = 2
and field3 = 3
order by field2, field3
Using the current HeidiSQL version I need to use the id to find the row and then change them one at a time.
What I actually do is run version 3.2 of HeidiSQL and update the query result. A recent data change I made to 400 rows took 5 minutes instead of a couple of hours (and with no mistakes because it's so easy).
I understand your reluctance to provide query result update because of the damage some might do to their database, but perhaps a new type of query tab function that permits only one table to be specified could control this.
Editable query results: see issue #723.
The problem occurred before version r2688, does not when I use version r2688 now, and does again in subsequent versions. This indicates to me that it's in the code. Do you agree?
When I downloaded version r2688 several months ago the notes clearly said that access had been made more efficient, so I think if you look at the release notes around this time you'll see exactly what the fix was.
Regards, and as always, thanks for a great program.
Please login to leave a reply, or register at first.