Results Pane Disappeared!

[Simeon]

I've just upgraded to 6.05 Community a couple of days back (on XP pro SP2), and have noticed many improvements – thanks!

BUT..

I was editing a big piece of code (a SQL Dump file) and hid the object explorer, and the results pane (Ctrl+1, Ctrl+2) and now I can't get the results pane to come back! The object explorer is happy to come and go, but the results pane has permanently gone..

I've tried re-installing over the top, but that didn't work.. <_< Any ideas, or is this a good, old fashioned bug? Thanks.

[peterlaursen]

very strange indeed! Ctrl+2 works perfectly for me! and we have no other report of such issue.

You are sure you don't Ctrl+F2 instead?

Also the divider has not been moved to lowest postion?

If your are totally 'locked' then you can try renaming the sqlyog.ini file before starting SQLyog. A new one will be created from scratch then

[Simeon]

peterlaursen wrote on Aug 15 2007, 08:18 PM:

very strange indeed! Ctrl+2 works perfectly for me! and we have no other report of such issue.

You are sure you don't Ctrl+F2 instead?

Also the divider has not been moved to lowest postion?

If your are totally 'locked' then you can try renaming the sqlyog.ini file before starting SQLyog. A new one will be created from scratch then

100% sure that I wasn't Ctrl+F2ing.. and the divider was in the middle when I hid it.

I was completely locked, so I uninstalled, restarted, and reinstalled.. which was completely unnecessary now that I know about the sqlyog.ini!

I'll see if I can replicate the problem and let you know.

[Simeon]

Simeon wrote on Aug 16 2007, 09:21 AM:

100% sure that I wasn't Ctrl+F2ing.. and the divider was in the middle when I hid it.

I was completely locked, so I uninstalled, restarted, and reinstalled.. which was completely unnecessary now that I know about the sqlyog.ini!

I'll see if I can replicate the problem and let you know.

Hmm.

No, I can't seem to make it happen at the moment.

[Simeon]

This fault is reproducable in 6.06

Open a query pane. Ctrl+2 to hide the results pane. Ctrl+t to open a new tab. The tab opens with the results pane hidden. Now.. Ctrl+2 to unhide the results pane.

It doesn't un-hide..

The explorer pane seems to handle hiding/unhiding appropriately regardless.

Perhaps something is being inherited incorrectly?

To reproduce my original fault: Close SQLYog while the active query tab has the results pane hidden. Re-open SQLYog, and try to unhide the results pane. (take a copy of your sqlyog.ini file first though!)

[peterlaursen]

verified!

Thanks for your research!

[Simeon]

peterlaursen wrote on Aug 30 2007, 09:48 AM:

verified!

Thanks for your research!

Peter, I just had a system lockup, and had to reboot. (Thanks Macromedia!)

Unfortunately for me, this happened while I had the results pane hidden. Now I can't get it back at all. I have uninstalled 6.06, deleted the folder from 'program files', rebooted, and re-installed it, but magically, it has managed to retain the connection list, and the fact that it doesn't want to show me the results pane.

I have un-installed 6.06, and now re-installed 6.05 which works nicely (but that doesn't help with the sqldump bug that 6.06 was created to resolve)

I had a brief snoop around the registry to see if I could find the 'artifacts' left behind by 6.06, but no luck yet.

Can you please give me details as to what I need to remove to get a 'clean' install of 6.06, or alternatively, if you have a version available that fixes both the 6.05 bugs, and the 'Results pane' bug I'd be keen to give that a try.

Thanks,

Simeon.

[peterlaursen]

In SQlyog 6.06 sqlyog.ini is stored in user's 'application data' folder. Deleting the installation folder will not delete this file!

But this issue should not occur with 6.06 at all.

Once you find the (really used) sqlyog ini, can we have a copy of it? Create a ticket if it contains details you do not want to expose in public?

[Simeon]

peterlaursen wrote on Sep 3 2007, 08:48 PM:

In SQlyog 6.06 sqlyog.ini is stored in user's 'application data' folder. Deleting the installation folder will not delete this file!

But this issue should not occur with 6.06 at all.

Once you find the (really used) sqlyog ini, can we have a copy of it? Create a ticket if it contains details you do not want to expose in public?

Thanks, that has solved it. Might need to look at adjusting the un-install process to clean up these left over folders too?

I've blanked out the passwords in the ini file, and attached it for you.

Interestingly, SQLYog 6.06b hasn't created a SQLYog.ini file in the application data folder yet, but seems to have created and updated one in the c:program filesSQLYog Community folder.

[peterlaursen]

Quote:

Thanks, that has solved it.

Sorry but what is THAT and what is IT?

did you copy the backup (and renamed it) to the new position? And old connections now appeared as well as you can now save connections?

If it was not like that then please explain in detail what you did and with what results!

[Marjolein Katsma]

Simeon wrote on Sep 3 2007, 11:32 PM:

Might need to look at adjusting the un-install process to clean up these left over folders too?

In general, an uninstall process removes only what the install process has created (using a log of the installation process) and does not remove any directories if they are not empty; some uninstallers are even polite enough to mention this.

Actually, this makes sense, since directories created by the installer may now hold data files that are still valuable to the user – the best option in this case would be to issue a warning what could not be removed. In addition, an (un)installer never has any notion of directories created by the running program (or by the user for the running program), so it could not possibly give even a warning about those, let alone remove them.

And what goes for directories and files in them usually also goes (more or less) for registry keys and values: what an (un)installer doesn't know about it cannot remove, though here a whole tree often will be removed when a top-level key is deleted, even if new subkeys had been created by the program.

[Simeon]

peterlaursen wrote on Sep 5 2007, 12:49 AM:

Sorry but what is THAT and what is IT?

did you copy the backup (and renamed it) to the new position? And old connections now appeared as well as you can now save connections?

If it was not like that then please explain in detail what you did and with what results!

Sorry Peter!

THAT = Finding the SQLYog.ini file in application data, deleting it's containing folder, then re-installing 6.06b

IT = my inability to see the results pane, and inability to re-install 6.06 to overwrite the existing 'glitch' in the ini file.

The last installation of 6.06b picked up the existing connections that I created in 6.05 and transfered them across (good..) As I had deleted all of the old SQLYog.ini files, there were no other connections for it to find.

Effectively I have performed a fresh upgrade from 6.05 to 6.06b.

[Simeon]

Marjolein Katsma wrote on Sep 5 2007, 03:11 AM:

In general, an uninstall process removes only what the install process has created (using a log of the installation process) and does not remove any directories if they are not empty; some uninstallers are even polite enough to mention this.

Actually, this makes sense, since directories created by the installer may now hold data files that are still valuable to the user – the best option in this case would be to issue a warning what could not be removed. In addition, an (un)installer never has any notion of directories created by the running program (or by the user for the running program), so it could not possibly give even a warning about those, let alone remove them.

And what goes for directories and files in them usually also goes (more or less) for registry keys and values: what an (un)installer doesn't know about it cannot remove, though here a whole tree often will be removed when a top-level key is deleted, even if new subkeys had been created by the program.

If I am un-installing a piece of software, my ideal expectation is that it will remove ALL of itself, and leave the system in a state like it had never been installed in the first place. Certainly, any folders created by the user I would expect to be left alone, but all configurations, connection details, preferences, reg keys etc should be removed. Like selling a house really – sure, some aspects of the property are still valuable to you, but you've decided to break your association with it. Having a bag full of keys, or tins of paint for a house you no longer own is not useful.

This seems a safer (and more realistic) approach than demanding that the software developers get their software perfect so that gllitches like the one I have identified can not occur. Obviously, complete removal is not a common approach, or we wouldn't have to re-install windows so regularly to remove left over 'junk' from software we have tried and then un-installed.

Failing that, there are a couple of solutions that I can think of off the top of my head-

A) Let the installer identify existing configuration files and ask if the user wants to retain, or overwrite them.

/:cool: shift any existing configuration files to a 'backup' folder somewhere, and notify the user so that the information can be 'salvaged' if required.

C) Only retain some parts of an existing configuration file (Only the connection details perhaps?)

[Marjolein Katsma]

Simeon wrote on Sep 4 2007, 11:13 PM:

Obviously, complete removal is not a common approach, or we wouldn't have to re-install windows so regularly to remove left over 'junk' from software we have tried and then un-installed.

It's not a matter of “approach” but simply that (un)installers have no knowledge of what the application they install does, what it does it with, or what files it might possibly produce. Installers only know about putting files in positions defined by the application developer, and creating registry keys for them, to simplify it a bit. You can't remove what you don't know about, let alone make a sensible decision when you don't know what it is other than “a file I haven't installed”. 🙂 That's why it is polite to actually not remove what it doesn't know about, but tell the user something's been left behind. Unfortunately, not all (un)installers are as polite as that.

(I have the habit to clean up after programs I uninstall, but that's because I test a lot of software; I clean up in the Registry, too, as far as possible. And I don't reinstall Windows regularly – in fact I've done that only once during the 6-odd years I've been using this machine, as a result of a crash due to a hardware problem – not “junk” left behind, and it's still quite stable.)

Simeon wrote:

Failing that, there are a couple of solutions that I can think of off the top of my head-

A) Let the installer identify existing configuration files and ask if the user wants to retain, or overwrite them.

/:cool: shift any existing configuration files to a 'backup' folder somewhere, and notify the user so that the information can be 'salvaged' if required.

C) Only retain some parts of an existing configuration file (Only the connection details perhaps?)

Option C) is a bit hard as the application developer would have to create a script for the installer to run to edit a file… and not all installer generators can do such a thing. Option A and especially B are actually fairly common (and easy to specify for almost all installer generators) – I have several applications with a “backup” folder created by the installer where replaced files are put – that also makes a “rollback” by uninstalling the later version fairly easy.

But for updates/upgrades I have a habit of either installing in a new, parallel directory, or making a complete copy of a program directory before installing a new version over it – I don't trust all installers to be so clever so I create my own insurance. If I'm really suspicious, I may even export all relevant Registry keys before installation as well. 😉

[Author]

Posts