2014.1 以前のアップグレード情報

フィールド・テスト・バージョンからのアップグレード

以前にリリースされたバージョンからのアップグレード

以前のバージョンの Caché を実行しているお客様は、インストール時にこのバージョンの Caché にアップグレードできます。複数のバージョンにまたがってアップグレードする場合、リリース間の互換性要件によっては段階的なアップグレードが必要となります。必要な情報は、中間段階の各リリースのリリース・ノートに記載されています。

アップグレードを開始する前に、システム・クラッシュなどの結果としてではなく、標準的な方法を使用して、インスタンスをシャットダウンしておくことをお勧めします。

各アップグレード・ステップの後に、次の条件が適用されます。

• 純粋なルーチン

  純粋なルーチンはバージョン間で上位互換であるため、リコンパイルは不要です。純粋なルーチンとは、以下のようなルーチンのことです。

  • クラス・コンパイルの結果として生成されたものではありません。

  • 操作の一部としてクラスを使用しません。さらに、

  • ルーチンまたはクラスのメタ情報にアクセスしません (バージョン X より前のバージョンでコンパイルしたコードのバージョン X でのソースレベル・デバッグの使用など)。

  ほとんどのバージョンでは、ルーチン・コンパイラ、生成されたコード、実行時サポートの効率性が改善されているため、ルーチンをリコンパイルすると、新機能を利用できるようになります。

  ルーチンをリコンパイルする場合は、先にクラスをリコンパイルしてからルーチンをリコンパイルする必要があります。

• クラス、SQL、プロジェクション、プロキシ・クラス

  アップグレード後に、すべてのカスタム・クラスをリコンパイルする必要があります。ユーザは自身で構築したプロシージャを使用してアプリケーション・クラスをリコンパイルする必要があります。または以下のコマンドを入力して、カスタム・コードでネームスペースにあるクラス・ディクショナリをアップグレードし、コンパイルします。

   ZN "namespace"
   Set StatusCode = $SYSTEM.OBJ.CompileAll("u")
   Do $SYSTEM.Status.DisplayError(StatusCode)
  

  "Caché 言語バインディング" セット内の該当するガイドの指示に従って、アップグレードしたインスタンスで使用されているすべてのプロキシ・クラスを再生成する必要があります。

  結果の詳細検証ができるようにするために、先のコマンド順序の出力をログに記録することをお勧めします。

  $SYSTEM.OBJ.CompileAllNamespaces() メソッドを使用してすべてのネームスペースをリコンパイルすることもできますが、HealthShare インストレーションをアップグレードする際はこの方法は使用しないでください。HealthShare に使用しているネームスペースは、リコンパイルしないでください。

• その他のルーチン

  前述の、純粋なルーチンの定義を満たしていないルーチンは、先にクラスをリコンパイルしてからリコンパイルする必要があります。データベースへの書き込みアクセス権を持っていることを確認し、各ネームスペースで次のコマンドを実行します。

  Do ##class(%Library.Routine).CompileAll()
  

• エクスポートした XML

  該当するリリースのアップグレード・ノートに記載されていない限り、エクスポートした XML ファイルを以降のリリースにインポートできます。

  ただし、新しいリリースから以前のリリースへ XML ファイルをインポートすることはできません。新しいバージョンは、以前のバージョンにない新機能を使用している可能性があります。また、クラス・ディクショナリのバージョン番号が異なる可能性もあり、その場合はそれらのクラスの内部的な格納方法が変わっているため、以前のバージョンへのインポートはできません。

• デバッグ

  開発中のアプリケーションのルーチンおよびクラスもリコンパイルすることをお勧めします。リコンパイルすることによって、想定されたコンパイル・コードのフォーマットでデバッガと同期化されます。

リコンパイルする際には、次の点に注意してください。

1. リコンパイルすると、ルーチンに関連付けられたシステム・データを更新する必要があるので、クラスやルーチンをリコンパイルするユーザには、コンパイルするオブジェクトがマップされている各ネームスペースの当該のデータ (^ROUTINE) への書き込みアクセスが必要です。この要件が満たされないと、[エラー #302 ： データベースは読取専用です] というエラーが表示されます。

2. コンパイルに必要なすべてのソースは、クラスまたはルーチンがマップされているネームスペースでアクセスできる必要があります。例えば、クラスまたはルーチンがユーザ定義のインクルード・ファイルを参照する場合、そのインクルード・ファイルもマップされている必要があります。そうすることで、コンパイラがソースを処理するときにファイルを特定できます。

3. 既定では、$SYSTEM.OBJ.CompileAllNamespaces はネームスペース “%SYS” および “DOCBOOK” をコンパイルしません。サイトで %SYS にクラスが存在する場合、これらのクラスを手動でリコンパイルする必要があります。HealthShare インストレーションでは、$SYSTEM.OBJ.CompileAllNamespaces を使用しないでください。

4. $SYSTEM.OBJ.CompileAll などの機能の使用が推奨されますが、これはコンパイルされるアイテム間の依存性に関する情報がすべて、アイテム自体の宣言に含まれていることを前提にしています。例えば、アプリケーション “コア” をアセンブルし、最終バージョンにブートストラップするような一部の複雑なアプリケーションは、これには該当しません。このような場合、ユーザは、コンパイラにはわからない、特にスキーマやドメイン固有の言語に関連した依存性に対処するようなコードをコンパイルするためのスクリプトを作成する必要があります。

5. これは必須ではありませんが、サイトが %SYS ネームスペースに [%]Z* という名前のルーチンを配置している場合、これらのリコンパイルをお勧めします。例えば以下のようになります。

   ZnSpace "%SYS"
   Set sc = $SYSTEM.OBJ.Compile("Z*,%Z*", "ck")
   
   

以前のバージョンとの互換性

インターシステムズは、あるバージョンの Caché で記述されたアプリケーションを、それ以降のバージョンでそのまま動作するよう取り組んでいます。ただしうまくいかないこともあります (そのためにこのドキュメントが必要となります)。しかし、その逆、つまり過去のバージョンで変更せずに動作することは保証されていません。

複数のバージョンの Caché で運用するアプリケーションを記述する場合、その中から最も古いバージョンの機能のみを使用するようにアプリケーションを設計および開発する必要があります。

Web アプリケーションの考慮事項

アップグレード計画と配置計画の一環として、以下に示す Web アプリケーションに関するインターシステムズからの重要な推奨事項について検討してください。

• セキュリティ保護された配置環境では、どの Web アプリケーションに対しても認証なしアクセスを許可しないでください。これを行うには、各アプリケーションの [ウェブ・アプリケーション編集] ページで、[許可された認証メカニズム] の下にある [認証なし] ボックスのチェックを外します。

• /csp/broker Web アプリケーションには、どのような認証方法も許可しないでください。これを行うには、/csp/broker の [ウェブ・アプリケーション編集] ページで、[許可された認証メカニズム] の下にあるすべての選択肢でボックスのチェックを外します。