Two ideas for HeidiSQL
| User, date | Message |
|---|---|
|
Written by muzza4
3 years ago Category: General 50 posts since Mon, 04 Dec 06 |
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 |
|
Written by ansgar
3 years ago 3974 posts since Fri, 07 Apr 06 |
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. |
|
Written by muzza4
3 years ago 50 posts since Mon, 04 Dec 06 |
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 |
|
Written by ansgar
3 years ago 3974 posts since Fri, 07 Apr 06 |
So, r2687 was slow, r2688 was fast and r2689 was slow again? |
|
Written by ansgar
3 years ago 3974 posts since Fri, 07 Apr 06 |
wrote: 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. |
|
Written by muzza4
3 years ago 50 posts since Mon, 04 Dec 06 |
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 |
|
Written by ansgar
3 years ago 3974 posts since Fri, 07 Apr 06 |
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. |