Two ideas for HeidiSQL

Hi Anse

HeidiSQL is great, but it has two big issues that from my point of view. I think they are important, maybe others will agree...

Reconnection
------------------
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
from tablename
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.

Regards
Muzza

Slow reconnection: No clue, heard that before, but I can't reproduce that here. Can you provide me some more details on that slowness? Probably you have file logging on your server and the logfile tells something interesting?

Editable query results: see issue #723.

Hi Anse

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.

Muzza

So, r2687 was slow, r2688 was fast and r2689 was slow again?

This indicates to me that it's in the code. Do you agree?

I don't - that's only a rough indicator, looking very random to me, as r2688 was a very minor internal optimization, which effects only databases with really huge numbers of tables.

Hi Anse

I don't know if r2688 was the only fast one as I don't download every version, so the change might have been a few versions earlier.

Huge numbers of table - is 212 a lot?

Regards
Muzza

Yes, 212 tables could take a while until loaded into the highlighter. Not sure what the problem is though.