[MDEV-25521] Bundled HeidiSQL cannot be upgraded Created: 2021-04-26  Updated: 2021-04-26  Resolved: 2021-04-26

Status: Closed
Project: MariaDB Server
Component/s: Platform Windows
Affects Version/s: 10.5.4
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Kjell Rilbe Assignee: Vladislav Vaintroub
Resolution: Not a Bug Votes: 0
Labels: heidisql, installer
Environment:

Windows Server 2019


Issue Links:
Relates
relates to MDEV-6908 Quit Installing HeidiSQL by default f... Open

 Description   

The bundled HeidiSQL installation is placed in C:\Program Files (x86)\Common Files\MariaDBShared\HeidiSQL and does not have a separate item in the Apps and Features list in Windows. Nor does the MariaDB item there have a Modify option, only uninstall.

When HeidiSQL detects that there is a new version, and that installer is launched, it doesn't detect the bundled installation and cannot upgrade it. As per this forum post, there is no way to upgrade the bundled installation of HeidiSQL. Instead you end up with a zombie installation in MariaDB's folder structure, and a new installation in the default (or chosen) location.

If MariaDB will continue to bundle HeidiSQL in spite of this issue, please bundle it in a way that allows it to be upgrade properly. Preferably, just install it as a proper separate package, as if it were installed separately.



 Comments   
Comment by Ansgar Becker [ 2021-04-26 ]

One solution without much effort could be to include the official HeidiSQL installer, and run it with a /SILENT command line parameter (or even /VERYSILENT)
The HeidiSQL installer is created using InnoSetup, which has a nice documentation on these parameters: https://jrsoftware.org/ishelp/index.php?topic=setupcmdline

Comment by Vladislav Vaintroub [ 2021-04-26 ]

Bundled installation is created out of a portable install. If upgrade does not work for portable install, * so that it remains portable*, HeidiSQL (not us) has a bug , that should be solved.

If upgrade does work for portable install, so that it remains portable, yet we mess up with it somehow, we'd like to know what we're doing wrong.

A portable installation was here by design, so it can be easily implemented as merge module. That was done a decade ago, I do not think this needs to change. I would not like to suddenly change that to centralized install, as I would not like to deal with upgrades and downgrades of software which might be already there. This is thought to be a MariaDB-private copy of HeidiSQL. (comparable to Visual Studio for example, that might install their private copies of 3rd party , like clang and cmake, that do not mess up with per-machine or per-user installations)

anse ^

To summarize, I think this is HeidiSQL issue, and portable installation should either

  • provide a portable upgrade, i.e replace the binaries in-place, in the directory that it is installed in
    or
  • should not provide update at all

That portable installation upgrades into per-machine, copies binaries elsewhere, and involves registry and what not, does not seem to make much sense.

Comment by Ansgar Becker [ 2021-04-26 ]

Ah, well I didn't recall it was the portable. So in that case this is not an issue at all, as the MariaDB copy of HeidiSQL is not really a duplicate of a normal HeidiSQL installation.
The portable version, including the MariaDB copy, has no automatic upgrade mechanism, apart from the automatic build update. Releases have to be copied by hand. Plus, you can have multiple portable versions beside each other, and besides a normal install.
@Kjell I'd suggest to upgrade the bundled copy by unpacking a fresh portable package.

Comment by Kjell Rilbe [ 2021-04-26 ]

Good! Sorted out then!

I'm following up at HeidiSQL site to suggest the update checker to give correct upgrade instructions for a portable install.

We can close this issue here.

Comment by Vladislav Vaintroub [ 2021-04-26 ]

Ok, thanks anse for explanation. We do periodically update the version of HeidiSQL, and it should be 11.2 in current (or, about to be released) versions.

Generated at Thu Feb 08 09:38:20 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.