Please publish requirements for installs to be able to have EBFs applied

[justin_willey]

This is an issue that has been discussed a few times before - in most depth here.

Presently ebfs cannot be applied to installs made by custom installers or those created through the Deployment Wizard. This means that for every ebf that might be needed, new installers have to be created, tested etc when only the Sybase components are changing. For some users this does not present much difficulty, but for those with large distributed install bases it does. Also, as we know in support cases, the first question is always (and reasonably), have you installed the latest ebf? Again on these occasions new installers have to be built speculatively.

Although re-building an installer after applying an ebf on the originator machine is not that great an undertaking, then testing it say XP, Vista, Windows 7, Server 2003, Server 2008, with 32 and 64 bit flavours certainly is!

Of course if one wanted to have a custom installer be capable of having an ebf applied, one would have to accept restrictions about how one installed the Sybase components and probably do some extra work, but for many that would be a price worth paying for the ability to quickly apply an ebf when that is required.

[VolkerBarth]

On a related issue, the SQL Anywhere Client Installers (first released for v 12.0.1) seem to have not been EBF'ed so far.

AFAIK, they are said to be "official setups" and can be EBF'ed by their own EBFs - not that helpful as long as they have none yet...

---

(I stumbled about that lately when I just wanted to get a 64-bit OLEDB client install - unfortunately, the Client Installer installs all client interfaces by design, what was undesired in this case.)

[justin_willey]

I've always thought that being "EBF'ed" sounds rather painful!

[VolkerBarth]

...still better than "EOL'ed":)

[jeff_albion]

This means that for every ebf that might be needed, new installers have to be created, tested etc when only the Sybase components are changing.

If you build the SQL Anywhere MSI components separate to your main software install, you can just build a new MSI for the SQL components when EBFing (assuming they use the same 'ProductCode' for the MSI). It shouldn't be any more difficult to deploy a replacement SQL Anywhere MSI than applying the "whole SQL Anywhere EBF install" to each client install.

Of course if one wanted to have a custom installer be capable of having an ebf applied, one would have to accept restrictions about how one installed the Sybase components and probably do some extra work, but for many that would be a price worth paying for the ability to quickly apply an ebf when that is required.

I have a "food for thought" question though if this were to (somehow) be allowed, in general: would you prefer the ability for your customers to be able to directly go to sybase.com and patch your underlying SA software version without your express permission as a software vendor?

[justin_willey]

Thanks for getting back on this Jeff.

On the first point, while I can see this would work for some people, it wouldn't for us, in that the decision "tree" about what to install isn't divided into "our components" and "Sybase components", but is rather more complex with both types of components being installed and various configuration steps happening as the user works through the install process.

On the second question, again for us, this is something I would not be too concerned about. We are talking here about EBFs, not major version changes. In fourteen years we've not had a single problem CAUSED by an EBF (but a lot fixed!), which is something of a tribute to the Sybase team. Applying an unauthorised update would invalidate a user's support agreement, and indeed there's nothing currently to stop them overwriting the recommended setup now with a trial version they download of a completely different version.

[VolkerBarth]

Following this question, the truly non-official description might simply say: Use the official ProductCode when generating your setup with the help of the Deployment Wizard. - Not recommendable for a few very good reasons, particularly as this will pretend your custom setup as an official one.

As long as you can assure your customers (or better: your in-house users) do not use "official SQL Anywhere setups" on their boxes, it even may work:) - However, for such cases, deplyoing a re-run Deployment Wizard'ed setup will usually be the safer alternative and won't require much more work...

[justin_willey]

So do you think that the ebf is looking for a range of possible GUIDs that it knows how to patch (ie any earlier ones of the same version eg 11.0.1) I wonder how many of the registry settings it needs under the key eg :

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionUninstall{220C7FD5-D9EB-445A-BC17-337B93231774} (that's 10.0.1.3931)

If it just needs the InstallLocation etc that's easy enough, but if it's going to want to read the install log etc that could get very messy.

We don't use the Deployment Wizard as our installers are doing a lot of other stuff at the same time, and deciding which components are required depending on all sorts of overlapping user choices.

[VolkerBarth]

IMHO, the "ProductCode" is relevant to decide whether an EBF can be applied or not.

The 11.0.1 ProductCodes are listed here.

The 12.0.1 ProductCodes are listed here.

But that's just my understanding, I haven't tried to use that method. It's just a conclusion from the documented information that you have to re-use the ProductCode of your Deployment Wizard'ed setups in case a newer install should update a former one.

[Former Member]

One thing to note, if the EBFs are using the standard Microsoft MSI installer natively (and not just wrapping their own installation program in enough fluff to make it look like an installation package) then you likely will need to reuse both the Feature codes and Component codes if you want to convince Microsoft that the upgrade package is intended for your installation.

I'd probably have to run something like DARK over an EBF upgrade file before saying that I know what I'm talking about, but a fully-native MSI file is very similar to a database (with tables, columns, rows, and foreign keys) and an upgrade package like a transaction log, you have to make sure all the expected rows with the proper PK values are in the right place if you want it to apply cleanly.

Fully-native MSI files are also extremely difficult to create and maintain too, the more shaved corners there are the more likely you would be able to get away with something like this.

[VolkerBarth]

Microsoft's ORCA tool may also be of help in such cases...

...and running ORCA's validation against a small MSI generated with Deployment Wizard on 12.0.1.3519 (containing only ODBC and OLEDB client components) reveals some possible flaws:

ICE05 ERROR The entry: 'ProductVersion' is required in the 'Property' table.
...
ICE24 ERROR Property: 'ProductVersion' not found in Property table.
ICE74 WARNING The UpgradeCode property is not authored in the Property table. It is strongly recommended that authors of installation packages specify an UpgradeCode for their application.

So there might be more to do in order to generate an updateable MSI file - possibly one should use adapt the ProductVersion and UpgradeCode properties accordingly.

(No, I'm no MSI expert at all...)

[justin_willey]

Thanks for the pointers - I'll investigate

[justin_willey]

That must be at least part of the problem - thanks

[jeff_albion]

We're now tracking a bug for MSI upgrades internally as CR #694604 - we intend customers to use the MSIs as I described above, but currently the MSI flags Volker mentioned that are missing (e.g. 'ProductVersion', 'UpgradeCode') are preventing the upgrade from succeeding. We will post back when we have an update for this issue.

[VolkerBarth]

Wow, so I have to re-evaluate my "no MSI expert at all" claim? (Just kidding.)