Ads were blocked - no problem. But keep in mind that developing HeidiSQL, user support and hosting takes time and money. You may want to send a donation instead.

Two ideas for HeidiSQL

muzza4's profile image muzza4 posted 11 years ago in General Permalink
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
ansgar's profile image ansgar posted 11 years ago Permalink
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.
muzza4's profile image muzza4 posted 11 years ago Permalink
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
ansgar's profile image ansgar posted 11 years ago Permalink
So, r2687 was slow, r2688 was fast and r2689 was slow again?
ansgar's profile image ansgar posted 11 years ago Permalink

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.
muzza4's profile image muzza4 posted 11 years ago Permalink
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
ansgar's profile image ansgar posted 11 years ago Permalink
Yes, 212 tables could take a while until loaded into the highlighter. Not sure what the problem is though.

Please login to leave a reply, or register at first.




Ads were blocked - no problem. But keep in mind that developing HeidiSQL, user support and hosting takes time and money. You may want to send a donation instead.