アプリケーションをアップグレードするときは、バージョン (MSIファイル)としてアップグレードするか、またはパッチ(MSPファイル)としてアップグレードするかを検討してください。これを決定する前に、それぞれのファイルがどのようにWindowsインストーラーで処理されるか理解することが重要です。
基本的に、Windowsインストーラーはバージョン・アップグレードをパッチではなくフルインストールとして処理します。アプリケーションの旧バージョンがターゲット・システム上にある場合、Windowsインストーラーは新しいバージョンをインストールする前に旧バージョンをアンインストールします。アプリケーションの旧バージョンがターゲット・システム上で見つからない場合、Windowsインストーラーはこれがアプリケーションの最初のインストールであるかのように、インストールを開始します。
一方、パッチのアップグレードの場合、Windowsインストーラーはまずアプリケーションのバージョンがパッチを受け取ることができるかを判断します。 アプリケーションのアップグレードが可能な場合、パッチに含まれる変更は既存のアプリケーションの上に適用されます。バージョンのインストールに対するパッチのインストールの主な利点は、パッチにはユーザーのアプリケーションの変更のみが含まれるため、通常、バージョンよりずっと小さいことです。
通常、パッチはアンインストールできないように設計されています。データベースの変更の管理は複雑なため、通常、データベースの変更はバージョンのアップグレードにより配布されます。データベースの変更は、アンインストールする時が特に複雑です。まず、データベースのユーザーが一人だけデータベースの変更をアンインストールしてください。データベースの変更は自動では取り消されません。具体的に要求してください。次に、Windowsプログラムにより標準のアンインストール処理が提供されます。ユーザー・インターフェースは機能では提供されないため、データベースの変更の取消を要求することはできません。機能の代わりにコマンド・ラインを使ってください。
省略値ではパッチはデータベース変更をアンインストールしません。この是非は複雑な問題です。パッチにデータベースの変更が含まれる場合、このパッチの削除方法、もしくは配布ツールのパッケージでパッチのアンインストールを無効にする方法について、管理者に十分な説明をする必要があります。
データベース変更をアンインストールするには、以下のようにコマンドラインで misexec を実行する必要があります。
例:
msiexec /package C:\DEV\TRUNK\WORK\X_WIN95\X_LANSA\X_APPS\PATCHDB\PATCHDB_v2.0.0_en-us.msi /uninstall C:\DEV\TRUNK\WORK\X_WIN95\X_LANSA\X_APPS\PATCHDB\PATCHDB_v2.0.0.5_en-us.msp SUDB=1 /qb
パラメータ SUDB=1 /qb は任意です。これが指定されていな場合は、ダイアログが表示され、手動で Setup DB をオンにすることができます。
注: これは機能面での手順の説明です。データベース変更を元に戻す前に、必ずそれぞれの状況についての十分な検討を行ってください。データベースが共有されている場合、ユーザーの1 人だけがデータベース変更のロールバックを行うようにしてください。残りのユーザーは、[プログラムと機能] からパッチの省略値アンインストールを行います。
または、データベースの変更を含んだパッチを取り消すには、別のパッチを作成し、データベースのオブジェクトを元の状態に戻す必要があります。
バージョンのアップグレードの使用を考える理由は以下のとおりです。
パッチのアップグレードの使用を考える理由は以下のとおりです。
注: パッチのインストールおよびアンインストールはバージョン・のインストール・ロジックを使用します。ですから、LANSA のリリースに追加された新機能のパッチでは、まず新しいパッケージ・バージョンの配布が必要です。その後、アプリケーションにパッチされた新しい LANSA 機能が利用できるようになります。
これは、以前のLANSA バージョンで作成されたバージョンのパッチが、パッチのプログラムとバージョンのプログラムの互換性がないため、正しく作動しなくなる可能性があることも意味しています。そのため、バージョンを生成した LANSA 構成はアップグレードしないことが強く推奨されています。そして、現場でサポートが必要なLANSA バージョンごとに生成の構成を別々に保管しておく必要があります。
例えば、LANSA バージョン 13.0 と 13.1 の両方のアプリケーションのユーザーを維持する場合、バージョン 13.0 と 13.1 の両方の構成を保管する必要があります。いずれにしても、アプリケーションの異なるリリース間の変更を最小限に止めるためにも、この方法を習慣づけると良いでしょう。もちろん、アップデートを受け取るには、アプリケーションを最新バージョンにアップグレードするよう、全ユーザーに義務付けることも可能です。そうすれば、1 つの生成構成を管理するのみとなります。