Skip to main content

This is documentation for Caché & Ensemble. See the InterSystems IRIS version of this content.Opens in a new tab

For information on migrating to InterSystems IRISOpens in a new tab, see Why Migrate to InterSystems IRIS?

Caché 2009.1

この章では、Caché 2009.1 の以下の項目について説明します。

Caché 2009.1 の新機能と強化機能

今回の 2009.1 リリースでは、Caché に次の機能が加わりました。

このバージョンの Caché では、次の分野の機能が向上しています。

さらに、これ以外にも、さまざまな点で機能強化や改善がなされています。特に既存のインストール環境をアップグレードする場合は、"アップグレード・チェックリスト" で詳細な変更内容を確認してください。

パフォーマンスとスケーラビリティ

クラス・コンパイラの最適化

クラスのコンパイル時間を短縮するために、さまざまな改良や変更が行われています。増分コンパイルのような今後実行するコンパイルでコンパイル済みコードを再利用するための追加情報を、コンパイラで生成できるようになりました。

これらの改良点の中には、このリリースで実行するために既存のクラスの変更が必要になるものがあります。"アップグレード・チェックリスト" を参照して、実際のアプリケーションへの影響を評価してください。

XML パフォーマンスの向上

XML パーサの内部コンテンツ・ハンドラが最適化され、Caché との効率的な対話処理が実現しました。これにより、複雑な XML ドキュメントをロードする際のパフォーマンスが大幅に向上します。

ネームスペース有効化の高速化

このリリースでは、ネームスペースの有効化に要する時間が短縮されています。その効果は、多くのネームスペースや複雑なサブスクリプト・レベル・マッピングを持つ Caché インスタンスで最も顕著です。

迅速なアプリケーション開発

Informix ストアド・プロシージャ・コンバータ

このバージョンでは、Informix SPL ルーチンを Caché クラス・メソッドに変換する機能が追加されました。この変換で得られるクラス・メソッドには、一時テーブル、DEFERRED 構文の解析、例外処理などの Informix SPL 動作と同じ動作を実現できる Caché ObjectScript コードが記述されています。必要に応じ、すべての変換されたルーチン、発生したエラー、および生成されたクラスとメソッドの名前をログに記録できます。変換中に発生したすべてのエラーの要約もログの末尾に記録されます。

.NET ゲートウェイ

.NET ゲートウェイは、カスタム .NET コンポーネントのプロキシ・クラスを生成する API、または ADO、Remoting、ASP.Net などのパッケージのプロキシ・クラスのマッピングを生成する API を提供します。 生成されたプロキシ・クラスには、Caché Basic、MVBasic、または ObjectScript を使用して Ensemble または Caché からアクセスできます。 アプリケーションは、ローカルに置いたシステムまたは TCP/IP 接続を介してリモートに置いたシステムの Microsoft Common Language Runtime (CLR) に対してメソッド呼び出しを発行できます。

スタジオの機能強化

スタジオは、Microsoft Visual Studio 2008 を使用して、このバージョンに再実装されました。 これにより、ユーザ・インタフェースの外観や使用感が、最新の傾向を反映したものに更新されました。このバージョンでは、スタジオの機能に変更はありませんが、グラフィックやアイコンが新しくなり、個人ワークスペースをはるかに柔軟に管理できるようになっています。

2009.1 では、スタジオのパフォーマンスを向上するためのその他の重要な作業も行われました。 このバージョンでは、クライアント側にクラスのキャッシュ処理とインデックス作成の機能を実装しているので、クラスのロード時間が飛躍的に短縮されています。スタジオの起動ごとに、サーバとの間でインデックスがチェックされます。インデックスの変更が検出されなければ、クラスがローカル・キャッシュからロードされます。変更があったクラスは、無効化されてサーバから再度フェッチされます。この変更は、ネットワークを介してスタジオを使用するユーザに最も大きな利点をもたらします。

Zen レポート

以前のバージョンで導入された Zen レポート機能が、今回のバージョンで大幅に強化されました。 新しい機能は、以下のとおりです。

  • 外部 XML データ・ソースおよび XSL スタイルシートを使用する機能

  • レポート内の条件付きの要素およびスタイル

  • クエリによる事前定義を使用せずに、レポートの中で実行時にソーティングする機能

  • ピボット・テーブルの基本レベルのサポート

詳細は、"Zen レポートの使用法" を参照してください。

信頼性、可用性、保守性

IPv6 のサポート

Caché は、IPv6 アドレスを使用できるように機能強化されています。IPv6 を有効にした Cache では、IPv6 または IPv4 のいずれの形式の IP アドレスでも、ドメイン修飾子を持つホスト名またはドメイン修飾子を持たないホスト名として受け取ることができます。IPv6 は、すべての TCP/IP 接続でサポートされています。IPv6 の使用法の概要および関連する IETF (Internet Engineering Task Force) ドキュメントへの参照も確認してください。

構成ファイルの堅牢性

このリリースでは、構成ファイルの堅牢性向上を図る数多くの変更が採用され、さらに構成ファイルを変更するためのさまざまな編集作業を考慮した信頼性の高い内部構造も実現しています。以前のバージョンで有効なファイルは、このバージョンに初めてアップグレードする際に新しい形式に自動的に変換されます。

WARNING:

CPF ファイルが無効であると、Caché のインストールや起動ができない場合があります。

Important:

インターシステムズでは、技術アシスタンス・プログラムにサブスクライブしているお客様を対象として、2009.1 をインストールする前に CPF ファイルの有効性をチェックする個別プログラムを提供しています。このプログラムは、WRC DirectOpens in a new tab ページで入手できます。ログイン後に、表示されるオプションから [CPF の検証] を選択してください。

ユーザ ID およびパスワードをお持ちでない場合は、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

Caché データベース領域の開放

このバージョンの Caché では、使用していないデータベース領域を解放する機能が導入されました。この機能では、データベース・ファイルの末尾にある空きブロックを切り離し、要求された領域を直ちにファイル・システムに解放できます。 この領域解放は、^DATABASE ルーチン・メニューまたは SYS.Database API を使用して要求できます。

Note:

この機能は、現在のところ Windows および Unix® のプラットフォームでのみ使用できます。また、ブロック・サイズが 2 KB のデータベースや raw ボリュームを持つデータベースには使用できません。

SNMP および WMI によるシャドウの監視

今回のバージョンの Caché では、SNMP または WMI インタフェースを使用したシャドウ・ジャーナリングの監視機能が追加されました。追加されたデータ・オブジェクトは、システム管理ポータルの ホーム, 構成, シャドウ・サーバ設定 ページでデータが利用できるようになっており、それぞれのデータ・ソースおよび宛先のシャドウ・サーバの接続に関する情報を格納しています。

正確なオブジェクト名、構造、および実装に関する詳細は、Caché の MIB (ISC-CACHE.MIB) ファイルまたは MOF (IscProv.mof) ファイルを使用して確認できます。これらのファイルは Caché インスタンスごとにインストールされます。

64 ビット Macintosh のサポート

このリリースでは、Macintosh OS X 64 ビットのサポートが追加されました。

管理ポータルの再編成

システム管理ポータルにさまざまな変更や機能強化が加えられました。

  • 構成

    構成ページでは再編成が行われ、さらにわかりやすいレイアウトになりました。これにより、適切な情報を見つけやすくなります。

  • SQL

    独立したページで、FILEMAN のデータ・ソースを管理できるようになりました。

  • データベース

    データベース内の空き領域を解放するという管理者のための新機能を実行するメニューが追加されました。管理者は、データベース内の選択したグローバルに対する整合性チェックを管理ポータルから実行することもできます。

  • ライセンス

    ユーザによるライセンス使用状況を管理ポータルで表示するためのオプションが、ライセンス・ページに追加されました。

埋め込み可能インストール

今回のバージョン以降、Windows への Caché のインストールでは、ネイティブの .MSI のインストール機能を使用します。Microsoft の Orca などの MSI エディタを使用して、必要なコンポーネントのインストールとアプリケーション固有のコンポーネントの組み込みのみを扱うようにインストールをカスタマイズできます。

さらに、アプリケーションでインストール・マニフェスト・クラスの作成に使用できる新しい 2 つのパッケージとして、Config と %Installer が追加されています。製品のインストール中にこのクラスを実行すると、次のことが可能です。

  • ネームスペースとデータベースの作成

  • グローバル、ルーチン、およびパッケージのマッピングの定義と有効化

  • グローバル、ルーチン、およびパッケージのロード

  • ロードしたルーチンおよびパッケージのコンパイル

  • 指定したルーチンおよびクラスの実行

パッケージと使い方については、"Caché インストール・ガイド" の “インストール・マニフェストの作成および使用” の章で説明されています。

セキュリティ

XML 暗号化

このリリースでは、Caché の Web サービスおよび Web クライアントから送信された SOAP メッセージの XML 暗号化が導入されています。この実装は、WS-Security 1.1 に基づいており、メッセージ・ヘッダに EncryptedKey 要素を記述して X.509 証明書を使用します。詳細は、"CachéCach Web サービスの保護" を参照してください。

配布

Caché 2009.1 アップグレードのチェックリスト

目的

このセクションでは、Caché 2009.1 の機能のうち、このバージョンで大きく変更されたことから、従来のシステムの管理、運用、または開発の作業に影響を及ぼすものを取り上げます。

前回リリースよりも前のリリースからアプリケーションをアップグレードする場合は、その中間に存在するリリースのアップグレード・チェックリストにも目を通すことを強くお勧めします。このドキュメントでは、2008.2 と 2009.1 の違いのみを取り上げています。

このドキュメントの冒頭に記載したアップグレードの説明は、このバージョンに適用されます。

管理者

このセクションでは、以前のバージョンの Caché の管理作業を熟知しているユーザを対象に、バージョン 2009.1 の管理に関する新機能と変更点を説明します。ここでは、各項目について簡単に説明します。ほとんどの場合は、ドキュメントの別の箇所に詳しい説明があります。

CPF ファイルの変更

構成パラメータ・ファイル (CPF) の形式とコンテンツが大きく変更されています。また、システム起動時のファイルの検証がさらに厳密なものになっています。以前のバージョンで有効なファイルは、2009.1 に初めてアップグレードする際に新しい形式に自動的に変換されます。

WARNING:

CPF ファイルが無効であると、Caché のインストールや起動ができません。システムをこのバージョンにアップグレードする前に、現在アクティブな CPF ファイルを検証してエラーを修正する必要があります。CPF ファイルの検証および修正は、システムをアップグレードする数日前に行い、アップグレードの直前には再確認を行って、アップグレードの前にすべての問題が解決されるようにします。

特定のシステムをアップグレードする前に CPF ファイルを検証するには 2 つの方法があります。

  1. インターシステムズでは、技術アシスタンス・プログラムにサブスクライブしているお客様を対象として、2009.1 をインストールする前に CPF ファイルの有効性をチェックする個別プログラムを提供しています。このプログラムは、WRC DirectOpens in a new tab ページで入手できます。ログイン後に、表示されるオプションから [CPF の検証] を選択してください。

    検証する CPF ファイルのディレクトリおよびファイル名を入力するよう求められます。ファイルが WRC にアップロードされ、検証されてから、すべてのエラーが一覧表示されます。すべてのエラーを修正し終えるまで、エラーの修正とファイルの再検証を繰り返します。

    ユーザ ID およびパスワードをお持ちでない場合は、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

  2. 2009.1 がインストール済みのシステムから、ターミナル・セッションを開始します。ターミナル・セッションから、%SYS ネームスペースで、次のように検証ルーチンを実行できます。

    Set Status = ##Class(Config.CPF).Validate(<CPFFILE>)
    

    <CPFFILE> には、現在アクティブな CPF ファイルのディレクトリとファイル名を指定します。ターミナル画面にはエラーのリストが表示されます。ここで CPF ファイルを編集して、エラーを修正し、検証ルーチンを再実行することができます。

どちらの場合も、修正をすべて行い、CPF ファイルを完全に検証してから、CPF ファイルを置き換えてシステムを再起動すると、新しい設定が有効になります。

現在アクティブな CPF ファイルのほかに別の CPF ファイルを使用する場合、それを使用する前に、検証ルーチンを実行してそれらの CPF ファイルに対するエラーを修正する必要があります。

パッケージ、ルーチン、およびグローバルのマッピングの変更

バージョン 2009.1 では、グローバル、ルーチン、およびグローバル添え字をマップする方法において、大きな変更が 2 つあります。

  1. これらの項目のルールは、統合されています。

  2. マッピング定義に誤りがあると、構成ファイルの検証エラーが出力されるようになりました。このエラーが発生すると、Caché が起動されなくなります。

以前のバージョンでは、グローバル添え字のマッピングは次のような範囲の重複ができませんでした。

A("A"):A("D")->DB1
A("B"):A("E")->DB2

ただし、グローバル・マッピングおよびルーチン・マッピングでは重複できました。この場合、マッピングは構成ファイル内の出現した順に適用され、エラーは暗黙的に解決されていました。例えば、次のようなマッピングがあったとします。

A:D ->DB1
B:E ->DB2

これは、システム起動時に

A:D -> DB1
D:E -> DB2

と暗黙的に解釈されていました。

Note:

範囲 “A:D” は数学的な半開区間 [A-D) として処理されます。つまり、この範囲は “A” から “D” の直前までの要素ということになります。

以前のバージョンでは、マッピングの順序は重要でした。2009.1 で使用されるマッピングの変換では、どのような重複でも重複のない同等のマッピング・セットに変換されます。以下のテーブルに例を示します。

以前のバージョンのマッピング 2009.1 で変換されるマッピング

B* –> SAMPLES

A:G –> USER

A:B –> USER

B:C –>SAMPLES

C:G –> USER

B:C –> SAMPLES

A:G –> USER

A:B –> USER

B:C –>SAMPLES

C:G –> USER

A –> SAMPLES

A:G –>USER

A –>SAMPLES

B:G –> USER

A* –> SAMPLES

A:G –>USER

A:B –>SAMPLES

B:G –> USER

A:G –> USER

B:H –> SAMPLES

A:G –> USER

G:H –> SAMPLES

変換プロセスでは重複のないマッピングが生成されるので、マッピングの順序は重要でなくなります。

2009.1 では、正しくサブセットが作成されていれば、重複するマッピングを CPF ファイルで指定したり、管理ポータルに入力することもできます。つまり、このテーブルの最終行の 1 列目にあるようなマッピングは、バージョン 2009.1 にアップグレードすると、その隣に示すように変換されます。ただし、システムがアップグレードされていることが判明すると、そのセットはエラーになります。

Important:

システムを 2008.2 から 2009.1 にアップグレードする前に、CPF バリデタを実行して、構成ファイルが想定どおりに正しく使用されているかどうかを確認することを強くお勧めします。CPF バリデタの実行方法は、"前のセクション" を参照してください。

重複マッピングがあるサイトでは、変換されたマッピングをテストして、既存のデータには引き続きアクセスできており、新しいデータも想定された場所に保存されることを確認することを強くお勧めします。

最初にプロダクションに移行する前に、すべての CPF ファイルが想定どおりに使用されているか検証してください。CPF ファイルを変換することなく、別の CPF ファイルに切り替えた場合は、最初に使用されるときに新しい形式に変換されます。

変換プロセスの詳細は、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

管理ポータルの変更

重複の解決に新しいルールができたため、構成ファイル内のマッピングの順序は関係なくなりました。そのため、次のような処理が行われます。

  • マッピングは、管理ポータルで現在のロケールの照合順に表示されます。

  • これにより、[下に移動] ボタンおよび [上に移動] ボタンは用途がなくなったので削除されています。

その他のマッピング変更

^oddPROJECT^CacheMsg、および ^CacheMsgNames グローバルのマッピングが変更されています。これらはネームスペースの既定のグローバル・データベースではなく、ネームスペースの既定のルーチン・データベースに格納されます。グローバルがすでに定義され、ネームスペースにそのネームスペースに対する別個のルーチン・データベースとグローバル・データベースがあるシステムでは、インストールにおいてシステムで定義されたすべてのネームスペースに対して、グローバル・データベースからネームスペースで定義されたルーチン・データベースへのマージが行われるものもあります。

アプリケーションが、同一のグローバル・データベースと各種のルーチン・データベースを共有する 2 つの異なるネームスペースで定義された ^oddPROJECT グローバルを持つ場合、最終的には ^oddPROJECT グローバルが一方のネームスペースに移動し、もう片方ではこれが表示されない結果となります。これを解決するには、ユーザが手動で ^oddPROJECT グローバルを一方のネームスペースからもう片方へコピーすることになります。

バージョン間の相互運用性

前回リリースとの相互運用性を示すテーブルが、サポート対象プラットフォームのドキュメントに掲載されています。

管理ポータルの変更

今回のリリースでは、新機能に対応し、また、既存マテリアルを使用しやすく構成し直すため、管理ポータルに多数の変更が加えられています。主な変更点は、以下のとおりです。

操作上の変更

システム・シャットダウン時のジャーナル待機時間の延長

シャットダウンするシステムは、ライト・イメージ・ジャーナル (WIJ) リカバリ情報にジャーナル・ファイルの終了が示されるまで待機しようとします。このような状況では、システムがシャットダウン状態を "起動時にジャーナル・リカバリは不要" として認識する場合があります。今回の変更では、ライト・デーモンがディスクへのブロック書き込みでビジー状態になる場合を考慮して、この待機時間が 1 分から 30 分に延長されています。これはあくまでも待機時間の変更であって、シャットダウンの動作自体に変更はありません。クラスタ・システムでは、リカバリが不要の場合にライト・デーモンが終了すると、リカバリが不要であることを知らせるため、ジャーナリング情報が WIJ から削除されます。

Caché 起動時のデータベースのマウント

バージョン 2008.2 の Caché では、すべてのデータベースをマウントしようとしていました。その結果、“[起動時にマウントが必要]” にチェックを付けておくと、Caché がデータベースをマウントできなかった場合は起動できませんでした。

2009.1 では、起動時に必要なデータベースの動作は同じです。一方、他のデータベースは、アクセスがあるまでマウントされません。この動作は、Caché の実行開始直後の管理ポータルで確認できます。

Note:

Caché では、インスタンスにアクセスできない設定の “ディスマウントされた” データベースと、使用可能であって、最初のアクセス時にマウントされる “マウントされていない” データベースが区別されます。

監査データベースの変更
インデックス・レコードの変更

タイムスタンプのインデックスが追加されて、監査データベースのクエリのパフォーマンスが向上しました。従来は、監査データの日時によるインデックスはありませんでした。2009.1 へのアップグレード後に Caché を再起動すると、スタートアップ時に起動するバックグラウンド・ジョブによって既存の監査データベースが新しい形式に変換されます。

このような変更があったため、監査レコード・グローバルの形式が変更されています。以前の形式は以下のとおりでした。

^CacheAuditD(<System>, <ID>) = $lb(<AuditDdata>)

新しい形式は以下のとおりです。

^CacheAuditD(<UTCTimeStamp>, <System>, <ID>) = $lb(<AuditDdata>)

アーカイブおよびレポートを目的として、サイトの監査データを別のネームスペースにコピーしている場合は、レポートを目的として ^%AUDIT ルーチンから初めてその監査データにアクセスする際にデータが変換されます。

アーカイブされた監査データベースに関するレポートの作成で SQL のみを使用するアプリケーションは、以下の 2 つのいずれかが実行されるように変更する必要があります。

  1. データのアーカイブ先とするネームスペースで ^%AUDIT を実行して、データに対してリスト・レポートを実行する。これによってデータが変換されます。

  2. データのアーカイブ先とするネームスペースで ##Class(%SYS.Audit).Convert() メソッドを実行する。

監査レコード形式の詳細は、%SYS.AuditOpens in a new tab クラスを参照してください。

必須でなくなった監査エントリ

これまでのバージョンでは、システム・レベルの監査イベントの中に、必須監査イベントとして指定されているものがありました。このため、管理者はこれらのイベントをオフにすることができませんでした。2009.1 の Caché では、どの監査イベントも無効化できるようになりました。既定では、以前のバージョンで必須と指定されていた監査エントリがそのまま必須になっているため、明示的にオフにする必要があります。

Note:

Security.EventsOpens in a new tab クラスのクエリが更新され、クエリから “Mandatory” 列が削除されています。これらのクエリを使用する場合は、これらの列を削除するための更新がアプリケーションに必要となる場合があります。

ネットワイド・ドメイン・ネームスペース (NWDS) の削除

2009.1 以降、ネットワイド・ドメイン・ネームスペース (NWDS) 機能はサポートされません。 NWDS を使用して、システムの境界をまたいでネームスペースの変更を伝達している場合、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

Telnet の既定の変換における変更

このリリースから、次のロケールでは、Telnet の既定の変換が RAW から UTF8 に変更されました。

  • araw

  • csyw

  • danw、deuw

  • ellw、engw、enuw、espw、eurw

  • finw、fraw

  • hebw、hunw

  • itaw

  • ltuw

  • nldw

  • plkw、ptbw

  • rusw

  • thaw

この変更の理由の 1 つとして、上記リストで Latin1 に基づくロケール (deuw、enuw、ptbw など) で、文字の値が 255 を超えるユーロ記号については、RAW を使用した telnet で処理できないことがあります。

Note:

UTF-8 には、ASCII. との完全な互換性があります。つまり、ASCII のみを使用する言語のロケールでは、変更に気づくことはありません。Latin1 に基づくロケールのうち、128 ~ 255 の値を持つ文字を使用するロケールのユーザは、アクセント記号付きの文字が正確に処理されるように、telnet クライアント・プログラムで使用しているエンコードを UTF-8 に変更することが必要になる可能性があります。

プラットフォーム固有の項目

このセクションでは、特定のプラットフォームに関係する項目について説明します。

Pentium P4 より前の CPU に対するサポートの終了

今回のバージョン以降の Caché では、Pentium P4 以降の (SSE2 CPU 拡張機能をサポートするチップセットを使用している) インテルベースのプラットフォームのみでインストールおよび実行できます。これは、Advanced Micro Devices (AMD) のチップセットなど、他のメーカーが提供するインテル Pentium P4 と機能的に同等なチップセットにも適用されます。

Note:

バージョン 2008.1 では、この制限はサーバ・システムのみに適用されていました。このバージョンでは、クライアントとサーバの両方に制限が適用されます。

Tru64 UNIX® のバージョンと構成の仕様
パッチ・レベル

Tru64 UNIX® システムは最低でも 5.1B-4 のレベルにアップグレードすることをお勧めします。これには、“fork 操作中にスレッドを無限に待機させる可能性のあるページテーブルのページ割り当ての問題” をベンダに従って修正することが含まれます。

スタック・サイズの制限

Tru64 UNIX® が稼働するシステムの中には、スタックのサイズを増加できないというオペレーティング・システムからのメッセージが表示されるものがあります。このメッセージの内容は、構成パラメータおよびアプリケーションの負荷により異なります。ulimit コマンドを使用すると、スタックにより多くの容量を割り当てることができます。

MultiValue クエリ

今回のバージョンの Caché では、Tru64 UNIX® のクエリで MultiValue はサポートされません。

Microsoft Windows
既定の Windows DSN と ODBC 3.5 との互換性の実現

Windows のインストール時に作成される既定の SAMPLES および USER DSN は、InterSystems ODBC35 ドライバを使用するようになりました。これは、新しいインストールでも任意のバージョンからのアップグレードでも使用されます。アプリケーションが Caché のインストールで作成された既定の DSN を使用している場合、ODBC 3.5 との互換性を確保するか、アプリケーションを特定の互換性のある DSN を参照するように変更する必要があります。

新しいインストーラによる ODBC ドライバ・バージョン管理の変更

新しい Windows インストーラでは、共通ディレクトリに ODBC ドライバ・キットのファイルと同じバージョンのファイルが存在すると、そのファイルはキット側のファイルで上書きされます。これより前のバージョンのインストーラでは、バージョン番号が小さいファイルのみがキットによって上書きされていました。前のバージョンと同様の動作にするには、以下のコマンド・ライン・オプションを使用します。

 ODBCDriver_x86.exe /V"REINSTALLMODE=omus"

バージョンにかかわりなく、該当するすべてのファイルを ODBC キットで上書きするには、以下のコマンド・ライン・オプションを使用します。

ODBCDriver_x86.exe /V"REINSTALLMODE=amus"

コマンド行から Caché をインストールする方法の詳細は、"Caché インストール・ガイド" の “Microsoft Windows への Caché のインストール” の章を参照してください。

古いインストールをアップグレードする際に新しいインストーラで発生する Windows エラー

新しい MSI ベースのインストールで非 MSI のインスタンスをアップグレードすると、ロールバックが無効になります。インストール・プロセスで問題が発生すると、どのファイルも削除されません。この動作は、古い形態のインストール環境でのアップグレードと同様です。通常は、エラーを解決した後でインスタンスを修復します。

新しいインストールおよび MSI インスタンスに対するアップグレードでは、引き続きロールバックが可能です。この場合、インストールやアップグレードの際にエラーが発生すると、システムは元の状態にリストアされます。

LAT 構成

config.cpf ファイルの [LAT] セクションは、今回のバージョンの Caché では不完全です。システム管理ポータルでは、ServiceName、ServiceDescription、および ServiceRating の通知サービスが構成されません。そのため、LAT デーモン (lat.exe) は、cache.cpf 構成ファイルからではなく、インストール・ディレクトリの lat.ini ファイルから起動パラメータを読み取るようになりました。LAT 機能を使用している場合、既存の cache.cpf ファイルの [LAT] セクションを新しい lat.ini ファイルにコピーするか、テキスト・エディタを使用してその情報を作成する必要があります。

サンプルの [LAT] セクションは、以下のとおりです。通知する LAT サービスは、最大 8 つまで指定できます。このサンプルは以下の 2 つの部分から構成されています。各サービスは、ServiceName、ServiceDescription、および ServiceRating で構成されます。

[LAT] 
NodeName= 
MessageRetransmitLimit=8 
HostMulticastTimer=60 
NodeGroups=0 
UserGroup
s=0 
ServiceName_1=CACHE 
ServiceDescription_1=Cache LAT service 
ServiceRating_1=1 
ServiceName_2=Cache2 
ServiceDescription_2=Second LAT device 
ServiceRating_2=1
Note:

LAT サービスは、Caché バージョン 2010.2 では非推奨になる予定です。

配布キットへの Weblink の添付中止

2009.1 以降、Caché インストール・キットに Weblink は同梱されなくなります。 各プラットフォーム向けの最新の Weblink パッケージは、サポート対象のお客様に無償で提供されています。これは、"インターシステムズのサポート窓口の配布ページOpens in a new tab" からダウンロードできます。

これらのキットには、Weblink のインストールおよび使用に必要なソフトウェア・コンポーネントおよびドキュメントがすべて含まれています。Weblink のインストール方法を説明したドキュメントは、Weblink キットの \doc\ サブディレクトリにあります。 ご不明の点については、インターシステムズのサポート窓口にお問い合わせください。

開発者

このセクションでは、以前のバージョンの Caché 上で実行されているアプリケーションの設計者、開発者、および保守担当者に関係する情報を示します。

ここでは、各項目について簡単に説明します。ほとんどの場合は、ドキュメントの別の箇所に詳しい説明があります。

一般的な操作上の変更

ルーチン・インポートのタイムスタンプ更新の変更

タイムスタンプがない XML 形式または %apiRTN を設定した %RO 形式のルーチンをインポートする際に、そのルーチンが既にシステム内に存在するものと同じであると、Caché では、ルーチンの最終変更時間が変更されません。

グローバル名を切り詰める方法の変更

グローバル名を最大長の 31 文字に切り詰めたときに、31 文字目がピリオドであると無効な名前が生成されていました。新バージョンでは、名前の切り詰め時に末尾のピリオドが削除されます。

この変更前は、アプリケーションの名前がこのような形式の場合でも、ZWRITE、^%GD、^INTEGRITY などから該当のグローバルにはアクセスできませんでしたが、アプリケーション自体はエラーを発生せずに実行できました。今回のバージョンでは、引き続きアプリケーションは実行できますが、その際に以前とは異なるグローバル名が使用されます。 Caché をアップグレードする場合は、既存のデータを認識できなくなります。

%BuildIndices へのビットマップ・エクステントの組み込みの既定化

ビットマップ・エクステント・インデックスが存在し、インデックス・リストにまだ組み込まれていない場合は、%BuildIndices によって構築される既定のインデックス・リストに組み込まれるようになりました。以前のバージョンでは、他のビットマップ・インデックスも構築済みで、ビットマップ・エクステント・インデックスがまだ組み込まれていない場合にのみ、自動的に組み込まれていました。

TROLLBACK 失敗時の処理の変更

今回のバージョンの Caché では、トランザクションのロールバックに失敗して、<ROLLFAIL> エラーを取得する際の処理が変更されています。このバージョンの動作は、システム・フラグ “ジャーナル・エラー時のフリーズ” の設定に基づき、ローカルの (ECP でない) トランザクションで以下のように処理されます。

  1. システム・フラグが設定されていない場合、プロセスはトランザクションを初期化し、TROLLBACK は <ROLLFAIL> エラーを取得します。トランザクションは閉じます。トランザクションで保持されていたロックは解放されます。このオプションでは、データ整合性よりシステムの可用性が優先されます。

  2. システム・フラグが設定されてる場合、初期化プロセスは停止され、ジョブ削除デーモン (CLNDMN) はオープン・トランザクションのロールバックを再試行します。CLNDMN が再試行している間、トランザクションで保持されるロックは損なわれませんが、システムは一時的に停止する場合があります。このオプションでは、システムの可用性よりデータ整合性が優先されます。

Important:

ECP 構成のトランザクションでは、ECP サーバのシステム・フラグで TROLLBACK の動作の失敗を管理します。ECP サーバのシステム・フラグが設定されていると、TROLLBACK を初期化する ECP クライアント・プロセスは停止し (ローカルの場合と異なります)、サーバの ECP ワーカ・デーモンはオープン・トランザクションのロールバックを再試行します。その他の処理は、ローカルの場合と同様です。

Note:

ジャーナリングを無効にしたプロセスでは (例えば、DISABLE^%SYS.NOJRN の呼び出しなど)、TROLLBACK が発行されるとその TROLLBACK の期間だけジャーナリングが有効となり、TROLLBACK が終了すると無効の状態に戻ります。以前は、このような状況で <ROLLFAIL> エラーが生成されました。

ストリームの既定ディレクトリのネームスペース別設定

バージョン 2009.1 では、既定のストリーム・ディレクトリが Caché の一時ディレクトリではなくなりました。既定のディレクトリはネームスペース別になり、ネームスペースごとに異なる場所を指定できるようになりました。既定の場所は以下のように定義します。

  • ECP データベースでは、引き続き CACHETEMP の格納場所が既定のディレクトリになります。

  • これ以外では、そのネームスペースのグローバルの既定ディレクトリの下位にある、stream という名前のサブディレクトリにストリームが格納されます。例えば、SAMPLES ネームスペースのストリームの既定ディレクトリは、<install-dir>/mgr/samples/stream です。

既定の場所は、各ネームスペースの Config.DatabasesOpens in a new tab クラスで、StreamLocation の値をプログラム上で設定することで変更できます。

IPv6 の変更

今回のバージョンの Caché で重要な追加機能は、IPv6 によるアドレスおよびネットワークのサポートです。ただし、IPv6 では新しい拡張形式でネットワーク・アドレスを指定します。IP アドレスの形式の受信および解析を前提としているアプリケーションは、IPv4 アドレスと IPv6 アドレスの両方を処理できるように作成し直すことが必要になる場合があります。

TCP デバイスの表現方法の変更

IPv6 を有効にすると、Caché によって返されるネットワーク・アドレスでは、ポート番号がコンマ (,) でネットワーク・アドレスから分離されています。これは、IPv4 では区切り文字であるコロン (:) が、IPv6 アドレスではネットワーク・アドレス自体に使用されているためです。

選択時のワイルドカードの禁止

Caché では、IPv6 アドレスに “*” などのワイルドカード文字を使用することはできません。IPv6 アドレスをフィルタとして選択する場合 (例えば、接続を受け入れまたは拒否する場合)、ホスト名または特定のアドレスを指定する必要があります。

Caché Direct の接続文字列の問題

Caché Direct では、IPv6 アドレス形式が完全にサポートされています。特に、VisM.ocx の Server/MServer プロパティでは、従来と同じ一般的な接続文字列形式で IPv6 アドレスを指定できます。ただし、アプリケーションで使用している方法によっては、解決する必要がある問題がある場合があります。特に、Caché Direct の接続文字列の形式は、一般的な形式のコロン区切りの式です。

CN_IPTCP:server_address[port]

server_address には、マスタ・サーバの IP アドレスまたはサーバの DNS 名、または “localhost” という特別な名前を指定します。

server_address の部分にコロンが含まれる IPv6 アドレスでは、競合が発生する可能性があります(IPv6 は、複数のループバック・アドレスの形式もサポートしています)。Caché Direct では、これらすべての形式をサポートしています。ただし、アプリケーション・コードの想定によっては、新しいアドレスは正しく解析されないと不正な動作を引き起こす可能性があります。

ObjectScript の変更

浮動小数点数の丸め処理の改善

今回のバージョンの Caché では、$DOUBLE 値を特定の小数点以下桁数に丸める際に使用するアルゴリズムの不具合が修正されています。 新しいアルゴリズムでは、この丸め処理の精度が向上し、中間処理の一部で発生していたオーバーフローが解消されています。

例えば、以下の式を考えてみます。

$NUMBER($DOUBLE(123456789.0123456) ,3)

この式は、値を小数点以下 3 桁に丸めることを要求しています。以前のバージョンでは、この結果が 123456789.01200000941 になりました。今回のバージョンでは、値 123456789.01199999451 が返されます。いずれの場合も、本来の値である 123456789.012 は得られません。

この理由は、この本来の値を 2 進数の浮動小数点形式では正確に表すことができないためです。2009.1 の丸めアルゴリズムでは、本来の値に最も近い範囲で正確な浮動小数点値が選択されます。

Caution:

この変更によって、固定小数点以下桁数の数値への xDBC 変換など、特定の桁数に丸める際に、値によっては以前のバージョンの場合と異なる値になるものが存在する可能性があります。

Caché では、カーネルの丸め動作も改善されているため、以下の影響が発生します。

  • $DOUBLE 値から小数点表記への変換で、有効数字が 38 桁を超えると、38 桁目で結果が丸められ、後続のすべての桁が 0 になる可能性があります。

  • 以前のバージョンでは、変換後の値の末尾に正しくない個数のゼロが続く不具合が発生することがありましたが、これが修正されています。

  • さらに古いバージョンでは、結果の下位の桁の丸め方が異なる場合があります。今回のバージョンでは、本来の値に最も近い範囲で表現可能な値に丸められるので、高い精度が得られます。

  • $DOUBLE() 値のすべての有効数字が、指定の小数点以下桁数よりも下位にある場合、生成される桁はすべて 0 になります (生成する前の数値が負の場合はマイナス記号も桁数に算入されます)。ただし、$DECIMAL() 値のすべての有効数字が、指定の小数点以下桁数よりも下位にある場合、生成される桁はすべて 0 になり、結果が負数であるかどうかは示されません。

    この動作は、以前のバージョンから変更されていません。 変更されている点は、$JUSTIFY では $DOUBLE(-0) が必ずマイナス記号付きの形式となり、書式文字列に "D" フラグを指定した $FNUMBER では $DOUBLE(-0) が負数表記となることです。

$ZUTIL(69, 4, ...) の撤廃

本来、この $ZUTIL 関数は、子ジョブの主デバイスを、その親が使用するデバイスと同一にすることを目的としていました。バージョン 5.1 以降、この関数は機能していません。今回および今後のバージョンの Caché では、関連ドキュメントも含め、この関数は撤廃されます。このエントリ・ポイントを指定すると、<FUNCTION> エラーが発生します。

現在のルーチンでの ZINSERT および ZREMOVE の使用禁止

実行中のルーチンの変更に ZINSERT および ZREMOVE を使用することはできなくなりました。 既存アプリケーションでこれを試行すると、コントロールが変更後のルーチンに戻ったときに <EDITED> エラーがスローされます。 以前のバージョンでは、変更が正しく検出されず、プロセスのアクセス違反が発生していました。 ルーチンからこれらのコマンドを正しく使用するには、XECUTE の中で ZREMOVE コマンドまたは ZLOAD コマンドの後に記述します。

ルーチン・コンパイラの変更

マクロ・プリプロセッサの修正

前バージョンで、以下の文をコンパイルするとします。

#dim X as %String // Length = 10

その結果、誤って以下の行が生成されます。

Set X=10

現在は、コメント記号 “//” が正しく処理され、コードは生成されません。また、マクロ・プリプロセッサでは、コメント内にプリプロセッサ指示語のような文が存在する場合に、正しく認識できるようになりました。このため、以下の文がコンパイルされることはありません。

#include %occInclude
        /*   
          A comment
#IF 0   
          Old comment
        */
#ELSE
          New comment
        */
#ENDIF  

クラスの変更

シグニチャ・チェックの強化

バージョン 2008.2 では、サブクラスのシグニチャ・チェックがクラス内のすべてのシグニチャ・エラーに適用されていました。しかし、状況によってはすべてのエラーがレポートされるとは限りませんでした。バージョン 2009.1 のコンパイラでは、すべてのシグニチャ・エラーがレポートされるため、すべてを一度に修正できます。

FileSet クエリの Size フィールド

%File:FileSet クエリによって返される Size プロパティが %Integer から %BigInt に変更され、サイズが 4GB を超えるファイルにも使用可能になりました。

未定義とすることも可能な %Dictionary.ClassDefinition の属性

Caché 2009.1 では、プログラムで定義するクラスで使用する属性を未定義状態にすることができます。以前は、参照されない属性は既定値であると見なされていました。現在は、%Dictionary.ClassDefinitionOpens in a new tab の属性ごとに新しいメソッド <AttributeName>Reset()<AttributeName>IsDefined() があります。

  • <AttributeName>Reset() を指定すると属性を未定義にすることができます。未定義の属性からは、Get の呼び出しで既定値が返されます。

  • 属性を任意の値に設定すると、その属性は定義済みとなります。

  • <AttributeName>IsDefined() では、属性の定義済みの状態が返されます。

  • 生成するクラスの定義に使用できる属性は、定義済みのもののみです。

Note:

これは、クラス %Dictionary.ClassDefinitionOpens in a new tab 自体にのみ適用され、メンバ定義クラスには適用されません。

XML DOM 内部表記の変更

XML DOM の表記に使用する Caché のデータ構造が変更されています。 その詳細は、内部使用として定義され、予告なく変更される場合があります。ただし、このデータに直接アクセスするアプリケーションは、変更してリコンパイルする必要があります。このデータにアクセスする方法として、%XML.NodeOpens in a new tab クラスの使用をお勧めします。

UPDATE での IDKEY 値変更の防止

割り当てた ID の値を変更することはできません。ID 値が変更不可能であることがドキュメントには明記されていますが、ソフトウェア側ではそれを適切に適用していませんでした。この不具合は修正され、IDKEY 値は更新できなくなりました。

SYS.DataBase.Freespace クエリの変更

SYS.Database.Freespace クエリを直接使用し、その結果セットにある名前で "%Free" データ列を参照するアプリケーションは、その列を番号または新しいラベル “Free” で参照するように変更する必要があります。これまで使用してきたラベルでは、正しい XML を生成できない障害が発生します。

クラス・クエリ名ではなくインクリメント・カウンタからのカーソル名の生成

タイプ %Library.SQLQueryOpens in a new tab のクラス・クエリを実装するために生成されるカーソル名は、クエリ名ではなくインクリメント・カウンタを基準にするようになりました。これによって、クエリ名の先頭の 29 文字が一意でない場合に発生する <LABELREDEF> エラーを回避できます。

GUID 管理の変更

永続クラスを GUIDENABLED と指定している場合、Caché では各オブジェクトの作成時に GUID (グローバル一意 ID) が割り当てられます。割り当てた後は、オブジェクトに対する %Delete を使用してオブジェクトを削除する呼び出しを実行しても、オブジェクトの GUID は削除されません。GUIDENABLED オブジェクトを作成したネームスペースごとに、GUID グローバルの履歴が保持されています。不要になったエントリを ^OBJ.GUID から削除する処理はユーザ側で実行する必要があります。

また、OID の GUID 値を返す %LIbrary.Persistent.GUID() メソッドに新しい引数が定義されています。この引数 pDeepSearch が True の場合は、該当のエクステントおよび登録されているすべてのサブエクステントを対象として、データベースに存在しなくなったオブジェクトの検索がトリガされます。以前は、削除したオブジェクトに対して実行した %OnDetermineClass は失敗し、GUID が見つかりませんでした。現在は、pDeepSearch が True であれば、現在のクラスのエクステントおよび登録されているすべてのサブエクステントで ID を検索できます。

%SerialObject のサブクラスとなった %Net.MailMessage および %Net.MailMessagePart

Caché 5.1 および Ensemble 4.0 より前のバージョンでは、%Net.MailMessageOpens in a new tab クラスおよび %Net.MailMessagePartOpens in a new tab クラスは %Library.SerialObjectOpens in a new tab のサブクラスでした。Caché 5.1 および Ensemble 4.0 以降は、%Library.RegisteredObjectOpens in a new tab のサブクラスに変更されています。さらに、今回のバージョンの Cache および Ensemble では、%Net.MailMessageOpens in a new tab%Net.MailMessagePartOpens in a new tab が再び %Library.SerialObjectOpens in a new tab のサブクラスになっています。

この変更によって、Caché 5.1 および Ensemble 4.0 より前のバージョンのアーカイブ・データに現在のアプリケーションからアクセスできます。

非推奨のクラス
%Library.Float

このクラスは、下位互換性を確保する目的でのみ用意されています。今後のアプリケーションでは以下のいずれかを使用してください。

Config.Configuration

Config.ConfigurationOpens in a new tab クラスは、今回の Caché バージョンから非推奨になりました。このクラスを使用しているアプリケーションは、Config.DatabasesOpens in a new tabConfig.DevicesOpens in a new tabConfig.TelnetOpens in a new tab など、このパッケージにあるより具体的な他のクラスを使用するように作成し直す必要があります。Config.ConfigurationOpens in a new tab は将来のリリースで削除される予定です。

%Net.LDAP

%NET.LDAP クラスは、今回の Caché バージョンから非推奨になりました。このクラスを使用しているアプリケーションは、%SYS.LDAPOpens in a new tab パッケージの同等のクラスを使用するように作成し直す必要があります。

クラスの削除

2008.2 バージョンに存在していた以下のパッケージのクラスは、バージョン 2009.1 では削除されました。

  • パッケージ %Monitor.System – Database、Sample.Database

  • パッケージ %Net.SSH – Session

  • パッケージ %SYS.Task – FreeSpace

  • パッケージ %Studio.Fireball – Error、Login、Namespaces、Probe

  • パッケージ %TSQL.Compiler – COS、Dynamic、Flo、ParseTree、Reflector、Visitor、sysSymbol

クラス・コンポーネントの削除

2008.2 バージョンに存在していた以下のクラス・コンポーネントは、今回のバージョンで使用可能なコンポーネントから除外されています。

  • %Activate.UI.Wizard

    メソッド : %OnSubmit、DrawTitle、Process、cbSelect、finish

    パラメータ : APPLICATION

  • %CPT.CalloutShell

    メソッド : cmdH

  • %CSP.UI.Portal.NLS

    メソッド : DrawLocale

  • %CSP.UI.System.MappingsAPI

    メソッド : CopyNamespaceMappings、GetTotalNumber、GlobalMappings、PackageMappings、RoutineMappings、UpdateDelete、UpdateMove

  • %CSP.UI.System.MappingsTablePane

    メソッド : IsMappingModified、MappingInfoClose、MappingInfoExecute、MappingInfoFetch

    クエリ : MappingInfo

  • %Debugger.System

    メソッド : Zbreak

  • %Library.EnsembleMgr

    メソッド : activateConfiguration、openConfiguration

  • %MV.StudioRoutines

    メソッド : Search、checkMatch

  • %Monitor.System.Dashboard

    メソッド : GetAppErrs、GetECP、GetSMH、GetShadows、GloStats

  • %Net.abstractMQ

    プロパティ : Password、Username

  • %SOAP.Security.BinarySecurityToken

    プロパティ : Id

  • %SOAP.Security.UsernameToken

    メソッド : Id

  • %SYS.LDAP

    メソッド : Test

  • %Studio.ClassMgr

    メソッド : ClassListClose、ClassListExecute、ClassListFetch、GetDefintion

    クエリ : ClassList

  • %Studio.Debugger

    メソッド : Zbreak

    プロパティ : PID

  • %Studio.Project

    メソッド : ExecuteCommand、checkMatch

  • %UnitTest.Manager

    プロパティ : TheLog

  • %UnitTest.SQLRegression

    メソッド : OnAfterAllTests、OnBeforeAllTests

  • %XML.Security.KeyInfo

    プロパティ : Key

  • %XML.Security.Transform

    プロパティ : content

  • %ZEN.Report.aggregate

    メソッド : method

  • Config.Configuration

    インデックス :NameIndex

    メソッド : %OnAfterSave、%OnBeforeSave、%OnDelete、%OnNew、%OnOpen、CPFExport、CPFImport

    クエリ : List

  • SYS.Cluster

    メソッド : IsMember

クラス・メソッドのシグニチャの変更

以下のメソッドは、呼び出しに必要なパラメータのリストまたは返される値の型のいずれかで、互換性のない変更が行われています。

  • %Activate.TLEnumerator

    引数リスト : LoadTypeLibrary

  • %Activate.UI.Wizard

    引数リスト : SetSelected

    返り値 : SetSelected

  • %CPT.CalloutDump

    引数リスト : DumpParseTree、DumpParseTreeNode、DumpParseTreeNodeAnn、DumpParseTreeNodeChild、DumpParseTreeNodeMap、DumpParseTreeTop、ListParseTree

    返り値 : DumpParseTreeNode、DumpParseTreeNodeAnn、DumpParseTreeNodeMap、DumpParseTreeTop、ListParseTree、ListParseTreeNode

  • %CPT.CalloutIndex

    引数リスト : BuildIndicesIfNeeded

  • %CPT.CalloutShell

    引数リスト : ParseLine、Run、cmdC、cmdR

  • %CPT.CalloutTesting

    引数リスト : Test、TestRoutine、TestStream

    返り値 : Test、TestRoutine、TestStream

  • %CPT.COSCallout

    引数リスト : Complile

  • %CSP.StreamServer

    引数リスト : FileClassify

  • %CSP.UI.Portal.NLSEdit

    引数リスト : EditIOTable

    返り値 : EditIOTable

  • %CSP.UI.SQL.UserPrivPane

    引数リスト : RevokeRow

  • %CSP.UI.System.LicensePane

    引数リスト : Save

  • %CSP.Util.AutoFormDynamic

    引数リスト : ProcessSubmit

  • %Compiler.Util.Flo

    引数リスト : addNode、pushNode

  • %Dictionary.ClassDefinition

    引数リスト : NameSet

  • %Exception.AbstractException

    引数リスト : OutputToStream

  • %IO.I.Stream

    引数リスト : ReadUntil、ReadUntilArray

  • %Installer.Installer

    引数リスト : ActivateConfiguration

  • %Library.EnsembleMgr

    引数リスト : createMappings、deleteMappings

  • %Library.File

    引数リスト : SubDirectoryName

  • %Library.FileStreamAdaptor

    引数リスト : GetStreamIdForFile

  • %Library.JGWResultSet

    引数リスト : CreateStaticRS

  • %Library.Persistent

    引数リスト : %GUID

  • %Library.ProcedureContext

    引数リスト : NewResultSet

  • %Library.RoutineMgr

    引数リスト : CompileClass

  • %Library.SyntaxColor

    引数リスト : Color、GetCSS

  • %Monitor.Alert

    引数リスト : GetId

    返り値 : Create、Delete

  • %Monitor.Manager

    引数リスト : StopSystemCounters

    返り値 : Activate、Alert、AppNotifyMethod、AppSmtpPassword、AppSmtpServer、AppSmtpUserName、ClearSystemCounters、Deactivate、Halt、HaltApp、Purge、Refresh、RefreshApp、SignalApp、SmtpPassword、SmtpServer、SmtpUserName、Start、StartApp、StartSystemCounters、StopSystemCounters

  • %Projection.AbstractProjection

    引数リスト : CreateProjection、RemoveProjection

  • %SOAP.WSDL.Reader

    引数リスト : Process

  • %SOAP.Security.SecurityTokenReference

    引数リスト : GetX509DirectReference

  • %SYS.Audit

    引数リスト : Exists、Get、Modify、OpenAuditItem、SearchExts

  • %SYSTEM.Error

    引数リスト : %OnNew

  • %SYSTEM.License

    引数リスト : DecodeAuth、SetUserLimit、Upgrade

    返り値 : Upgrade

  • %SYSTEM.OBJ

    引数リスト : Upgrade、UpgradeAll

  • %SYSTEM.SQL

    引数リスト : SetDefaultSchema

  • %Studio.AbstractDocument

    クエリ : CompileDocument

  • %Studio.ClassMgr

    引数リスト : SaveDefinition

  • %Studio.Debugger

    クエリ : IsStopped

  • %Studio.Project

    引数リスト : searchClassNode、searchItem

  • %TSQL.Transformer

    クエリ : Evaluate

  • %XML.Node

    引数リスト : AppendChild

  • %XML.Reader

    引数リスト : Correlate

  • %XML.Security.Signature

    引数リスト : ComputeSha1Digest、CreateX509

  • %XML.Writer

    引数リスト : CanonicalTree、Caonicalize

  • %ZEN.Controller

    引数リスト : OnPreHTTP

  • %ZEN.Report.Display.node

    引数リスト : %GetAbsoluteURL

  • %ZEN.Report.reportPage

    引数リスト : %DisplayFO、%getFileByRelativeURL、%ToXSLFOStyleSheetLink

  • Config.Configuration

    引数リスト : AddGlobalMapping、AddNameSpace、GetDataServer、RemoveNamespace

  • SYS.Database

    引数リスト : Compact、SilentIntegrityCheck

クラスとクラス・コンポーネントの予約

以下のリストにあるクラスとクラス・コンポーネントは、将来のインターシステムズで使用するために予約されています。これらを利用するアプリケーションは機能しますが、将来、該当の予告がなくても変更が必要になる可能性があります。このため、これらのクラスまたはクラス・コンポーネントを使用しているアプリケーションは、サポートされている代替手段を使用し、同等の結果が得られるように変更する必要があります。使用可能な変換オプションについては、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

  • %Library.ProcedureContext

    メソッド : NewResultSet

  • %Monitor.Alert

    メソッド : Create、Delete、GetId

  • %Monitor.Manager

    メソッド : Activate、Alert、AppNotifyMethod、AppSmtpPassword、AppSmtpServer、AppSmtpUserName、Deactivate、Halt、HaltApp、Purge、Refresh、RefreshApp、SignalApp、SmtpPassword、SmtpServer、SmtpUserName、Start、StartApp

クラス・コンパイラの変更

ジェネレータ・メソッドの順序

メソッド・ジェネレータを持つクラスで、ジェネレータのいずれかがクラス内の他のメソッドの状態に関する情報に依存する場合は、そのことをクラス・コンパイラに示す必要があります。これは、参照側のジェネレータ・メソッドのプロパティで GenerateAfter キーワードを指定することで可能です。このキーワードの後には、このジェネレータの実行前にコンパイルする必要があるメソッドの名前を指定します。

クラス継承の順序

複数の継承の実行時に共通メンバを解決する方法を指定する、新しいクラス・キーワードがあります。このキーワード Inheritance は、“left” または “right” (既定) に設定できます。共通のメンバ (例えばメソッド X()) を持つ 2 つのスーパークラス (以下の例ではクラス A とクラス B) からクラスを継承する場合は、次のように指定します。

Class User.C Extends (A, B)

既定では、最も右に記述したスーパークラスが他のスーパークラスより優先し、クラス C にはクラス B から X の実装が得られます。X() を使用してなんらかの作業を実行する別のメソッドがクラス A に存在し、クラス A ではなくクラス B から X の無関係な実装を突然取得することをクラス C で想定していない場合、この継承順序では問題が発生する可能性があります。

今回のバージョン以降は、inheritance キーワードを使用してクラス C への継承順序を指定できます。この例では、このキーワードの値に “left” を指定することで、所定の動作を実現できます。

^oddCOM からの cXXXXid ノードおよび cXXXinheritedid ノードの削除

クラス・コンパイラの処理速度を上げ、使用するデータ量を削減するため、cXXXXid および cXXXXinheritedid の各キーワード・ノードが ^oddCOM から削除されました。これらのキーワードは、クラス・コンパイラの内部キーワードなので、ユーザ・コードでは使用されていません。

アプリケーションでこれらの値を必要とする場合は、resolveIds^%occInherit(class,.inheritedid,.id) を呼び出して、システムに存在していた値を取得できます。

SQLPROC 設定に対する SQL クエリの依存

SQLPROC を 1 に設定したクエリのみがストアド・プロシージャとして投影されるようになりました。この変更前はすべての SQL クエリがストアド・プロシージャとして投影されていましたが、SQLPROC が 1 に設定されていないクエリは表示されていませんでした。したがって、“指定のない” これらのクエリは呼び出すことはできても、カタログ・クエリには表示されませんでした。この動作を利用しているアプリケーションは、更新する必要があります。

計算コードにおける $ET と Try/Catch の両立的使用

SQLCOMPUTECODE に $ET/$ETRAP を使用しているプロパティが存在することをクラス・コンパイラで検出した場合、生成された <property>Compute メソッドでは try/catch が使用されません。このため、エラー処理はユーザ側で実行する必要があります。この扱いは、$ZT/$ZTRAP に対する同様の変更に整合したものです。

%PurgeIndices で使用するインデックス名の検証

バージョン 2009.1 以降は、%PurgeIndices に渡したインデックスの名前が検証されるようになりました。現在のクラスで作成したものではないインデックスは削除できません。

Note:

ただし、このルールには例外があります。現在のクラスがエクステント・ルート・クラスであれば、ここで作成また継承したインデックスは構築および削除が可能です。

ジェネレータ・クラスのクラス名正規化の改訂

##class(Name).Method() などの不完全な参照をコンパイルする場合、コンパイラは、このクラス名を完全修飾クラス名に正規化しようとします。以前のバージョンでは、インポート・リスト、または該当の参照を含むこのメソッドの発生元 (メソッドが定義されたクラス) を正規化アルゴリズムで使用していました。しかし、ジェネレータ・メソッドは、事実上、そのメソッドが発生する各サブクラスに実装されます。

バージョン 2009.1 以降は、ジェネレータが最初に定義されたクラスではなく、ジェネレータ・メソッドの現在のクラスを基準として名前が正規化されるようになりました。

%this の使用に対する制約

以前のバージョンでは、以下のようなコードを実行すると、アプリケーションから別のオブジェクトのプライベート・プロパティにアクセスできました。

New %this
Set %this=otheroref
Set LocalValue=..PrivateProperty  

2009.1 以降、このコードはその本来の意図どおりには機能しません。これと同様のコードは変更する必要があります。これは、パブリックとプライベートとの間に Caché から適用する保護機能が強化されているからです。現在、クラス X のメソッドから別のインスタンスのプライベート・メンバにアクセスできるのは、そのメンバの発生元がクラス X またはクラス X のスーパークラスである場合のみとなっています。

クラス・メソッドによる ##this の使用禁止

以前のバージョンでは、インスタンス・メソッドからクラス・メソッドを呼び出し、そのクラス・メソッドから ##this 参照を使用して元のインスタンスにあるプロパティを参照できました。この使用方法では、##this の値の有効性をクラス・メソッドでは保証できないので、このような ##this の使用方法は禁止されました。このようなメソッドを実行するとエラーが発生します。

ストレージ・インタフェースの整合性チェック

SERIAL クラスと PERSISTENT クラスはいずれも、ストレージ定義を使用してクラスのインスタンスのシリアライズ方法を記述します。ストレージ定義では、必要なストレージ・インタフェース実装を提供するタイプ・クラスを指定します。SERIAL クラスの要件は PERSISTENT クラスの要件とは異なるため、適切なストレージ・タイプ・クラスが使用されるように、実際に使用するクラスとストレージ・タイプ・クラスとの互換性をクラス・コンパイラで確認するようになりました。互換性のないストレージ・タイプ・クラスはエラーとしてレポートされ、そのクラスのコンパイルは失敗します。

SQL プロシージャとして投影される EXTENT クエリ

%Library.PersistentOpens in a new tab で定義したエクステント・クエリは、自動的に SQL ストアド・プロシージャとして投影されます。このクエリが %Library.PersistentOpens in a new tab のサブクラスでオーバーライドされる場合は、クエリを投影するかどうかはそのサブクラスで決まります。

$DOUBLE 型の結果を返す %Double.DisplayToLogical

このクラスは、必ず $DOUBLE 型の結果を返すようになりました。

INCLUDECLASS の削除

以前のバージョンでは、一種の継承として、クラスから、そのクラスにインクルードする別のクラスを指定できました。この機能はまったく使用されなかったので、今回のバージョンでは削除されています。

<Property>Get メソッドの強制適用

以前のリリースでは、<propertyname>Get() メソッドはプロパティのように参照することができました。例えば、Age という名前のプロパティの場合、次のすべての文はコンパイルおよび実行できました。

  Write someobject.Age, !
  Write someobject.AgeGet(), !
  Write someobject.AgeGet, !

今回のリリースでは、コンパイラの構文チェックが強化されたため、最後の形式は正しく検出され、エラーが報告されるようになりました。

最終的なエクステント・ルート・クラスでの %%CLASSNAME の生成の抑制

エクステントのルート・クラスは、エクステントをインスタンス化する階層の中で最上位のクラスです。つまり、そのインスタンスをインスタンス化できる永続的なスーパークラスはありません。多くの場合、クラスは %Library.PersistentOpens in a new tab を拡張したものです (クラス自体にはストレージは割り当てられません)。エクステント・ルート・クラスのクラス・キーワード CLASSTYPE は “PERSISTENT” で、NOEXTENT は “FALSE” です。そのため、ストレージを割り当てるこのクラスのスーパークラスのリスト %%CLASSNAME は空になります。エクステント・ルート・クラスはそのようなクラスの先頭のクラスになります。

エクステント・ルート・クラスで FINAL が宣言されると、コンパイラにはサブクラスも存在しないと見なされます。このインスタンスでは、プロパティ %%CLASSNAME は常に null 値となってしまうので、このプロパティは生成されません。

IVARmultidimensional キーワードの削除

このキーワードを使用することを計画していましたが、実装されることはありませんでした。クラス・コンパイラのクリーンアップの一環として、このキーワードが削除されました。

オブジェクト・バインディングの変更

%Library コレクションのプロジェクション

%Library の “ListOf” コレクション・クラスおよび “ArrayOf” コレクション・クラスのいくつかが、次のように外部で投影されるようになりました。

%Library クラス プロジェクション スーパークラス
ListOfDataTypes CacheListOfDataTypes CacheListOfStrings
ArrayOfDataTypes CacheArrayOfDataTypes CacheArrayOfStrings
ListOfObjects CacheLibListOfObjects CacheListOfObjects
ArrayOfObjects CacheLibArrayOfObjects CacheArrayOfObjects

CacheListOfDataTypes、CacheArrayOfDataTypes、CacheLibListOfObjects、CacheLibArrayOfObjects の各クラスには、CacheConnection 引数を取るコンストラクタ (%New クラス・メソッドに相当) があります。

クライアント名の処理の変更

以前のバージョンでは、サーバ名にある文字のうち、C++ および C# ではクライアント名に使用できない文字を削除または置き換えることによって、必ずサーバ名からクライアント名が得られていました。2009.1 では、クラス定義のなんらかの名前としてサーバでクライアント名が定義されている場合、サーバ名を基に構成された名前ではなく、そのクライアント名が使用されます。サーバ名からクライアント名を取得するには、CacheConnection の GetClientNamesFromServer プロパティを True に設定したうえで、接続時に Open() を呼び出す必要があります。

.NET への MultiValue コレクションの投影

MultiValue コレクションは、他の Caché コレクションと同様、.NET バインディングに投影されるようになりました。この投影は以下のように行われます。

  • MV.ListOfDataTypes を CacheListOfStrings として投影します。

  • MV.ArrayOfDataTypes を CacheArrayOfStrings として投影します。

  • MV.ListOfObjects を CacheListOfObjects として投影します。

  • MV.ArrayOfObjects を CacheArrayOfObjects として投影します。

SQL の変更

Caché SQL での FOR ALL 拡張の非推奨

Caché SQL には、専用の拡張 FOR ALL が用意されています。これは、何年も前に、標準の FOR SOME 節を補完するものとして追加されました。これまでのいくつかのバージョンでは、FOR ALL を使用すると SQL 解析エラーが発生することが判明しています。しかし、この点に関連する不具合の報告がないことから、既存のアプリケーション・コードではこの拡張が使用されていないと推測できます。

このため、インターシステムズでは、2009.1 で FOR ALL の使用を非推奨にしました。この機能は将来のバージョンで削除される予定なので、既存のアプリケーション・プログラムでこの機能を使用している場合はプログラムを作成し直す必要があります。

UNION クエリのデータ型レポート

UNION から構築された列に適切なデータ型をレポートするように、SQL コンパイラが変更されました。以前のバージョンで、次のような SELECT 文を指定したとします。

SELECT 0 AS var1 FROM Table1
UNION ALL
SELECT 0.1 AS var1 FROM table2

この文を実行すると、xDBC に列のデータ型として INTEGER がレポートされ、データを切り捨てた整数として値 0.1 がクライアントに送信されていました。

現在は、SQL エンジンによってユニオンのすべての蓄積データが適切に調べられ、列ごとに最も高い優先度のデータ型が返されます。 Cache のデータ型の優先度は、高いほうから VARCHAR、DOUBLE、NUMERIC、BIGINT、INTEGER、SMALLINT、TINYINT の順です。例として、次のクエリを取り上げます。

SELECT MyTinyIntField AS var1 FROM Table1 
UNION ALL
SELECT MyIntegerField AS var1 FROM Table2
UNION ALL
SELECT MyNumericField AS var1 FROM Table3

この場合、NUMERIC の優先度が TINYINT や INTEGER より高いため、この列にデータ型 NUMERIC が返されます。今回のバージョンの Caché では、UNION でのデータ型に対する前述の優先度のみを使用します。 その他のデータ型が存在する場合は、自動型検出が行われません。 最も高い優先度を持つ UNION フィールドの型が返されます。 他の型は無視されます。データ型を明示的に変更するには、明示的な CAST 文を使用します。

INSERT ...SELECT TOP N のサポート

Caché SQL で、INSERT ... SELECT 文の最上位レベルのクエリで、TOP 節を使用できるようになりました。 例えば以下のようにします。

INSERT INTO Table2 (field1, field2)
SELECT TOP 10 fld1,fld2 FROM Table1

この場合、SELECT クエリで取得した上位 10 行のみが挿入されます。

この変更の前は、このクエリはエラーなく動作しましたが、TOP 節は無視されていました。 このため、結果がクエリと一致しなくなるという混乱が発生しました。また、以前はサブクエリで TOP 節を使用することができませんでした。 現在は、SELECT でサブクエリに TOP 節を使用すると、文の実行時にエラーが返されます。 このエラーは、以下のとおりです。

SQLCODE = -145 :: TOP clause is not valid in a subquery
新しいキーワード : %NOTOPOPT

Caché 5.2.2 以降では、TOP ... ORDER BY が最適化され、最初の行が生成されるまでの間隔が短縮されました。通常は、このような変更によってパフォーマンスが大幅に向上します。しかし、まれにこの最適化のヒューリスティックでクエリのパフォーマンスが低下する場合があります。そのような場合は、%NOTOPOPT ヒントを使用して、通常の総コスト最適化処理を実施できます。この構文は以下のとおりです。

SELECT TOP 5 *
FROM %NOTOPOPT mytable
...
ORDER BY x

大文字と小文字の区別を保持した状態での DISTINCT の実行速度の改善

バージョン 5.2 以降の Caché では、DISTINCTおよび GROUP BY でインデックスを使用できます。ただし、ほとんどの場合、この最適化では、大文字と小文字を区別している列が大文字で返されます。この動作を無効にするには、アプリケーションでその列の %EXACT() を選択する必要がありました。

バージョン 2007.1 の Caché では、この最適化の動作を制御する FASTDISTINCT ON 節または FASTDISTINCT OFF 節の使用が可能になりました。FASTDISTINCT OFF を使用すると、大文字で表記できる文字を大文字としたデータ値ではなく、実際の行データが返されます。しかし、FASTDISTINCT OFF を指定すると、インデックスによる DISTINCT のパフォーマンス改善は、未照合のデータをインデックスで格納している場合に実現します。ビットマップ・インデックスをはじめとして、ほとんどのインデックスにはデータが格納されていないので、この改善は実現できません。

FULL JOIN 節の処理の修正

バージョン 2008.1 以降、Caché は FULL OUTER JOIN をサポートしています。ただし、Caché は NATURAL FULL JOIN 節または FULL JOIN ... USING 節はサポートしていません。これまで、これらの構文形式を使用してもエラーにはならず、NATURAL LEFT JOIN または LEFT JOIN ... USING と同様に処理されていました。今回のバージョンからは、これらの形式を使用すると、節が不適切に処理されるのではなく、エラー・メッセージが生成されます。

計算プロパティの変更

SQLCOMPUTED であるプロパティでは、そのプロパティが CALCULATED ではなく、コレクションでもない場合に SQLCOMPUTECODE 内の現在のプロパティ値を参照できます。

抽象テーブルでの UPDATE と DELETE のサポート

Caché SQL では、実際に更新または削除する行がそのテーブルのサブエクステントに存在することを前提として、抽象テーブルに対する UPDATE および DELETE がサポートされるようになりました。 この変更以前は、READONLY と抽象が SQL では同等と見なされ、READONLY の動作が得られていました。 現在は、クラスを抽象として定義しておくと、ファイル用に更新する行の範囲に割り当てる UPDATE および DELETE のファイラに適したロジックが生成されます。

抽象テーブルに対する INSERT の実行は引き続き無効です。これを実行すると SQLCODE=-115 エラーが発生します。また、実際には行の UPDATE や DELETE を実行しない UPDATE 文または DELETE 文を抽象テーブルに対してアプリケーションで作成して実行すると、SQLCODE=100 が返されますが、これはエラーではありません。

Note:

アプリケーションで実際に READONLY テーブルを定義する場合は、READONLY クラス・パラメータを明示的に宣言する必要があります。READONLY として定義したクラスやテーブルに対して、アプリケーションで INSERT 文、UPDATE 文、または DELETE 文を実行しようとすると、SQLCODE=-115が返されます。

%PATTERN、%STARTSWITH、および文字列演算子の文字列比較

SQL 文での %PATTERN、%STARTSWITH、“[” (後続)、“]” (含む)、または LIKE の各演算は、文字列演算として実行されます。 演算子の両側が文字列値であると見なされ、例えば、以下のように処理されます。

 X %STARTSWITH '5.'

また、さらに極端な場合は、以下のようになります。

X %STARTSWITH '-.'

X が Numeric 型の場合、Caché は他の演算子の場合のようには '5.' を数値に正規化しません。その理由は、そうすると条件の意図 (それぞれ、5.<something> という形式のすべての数値、または -1 より大きいすべての負数) が変わるからです。

SQL での %Float 使用の削減

%Library.FloatOpens in a new tab として宣言されたデータは、ODBC データ型 DOUBLE として定義されます。 このため、%Library.FloatOpens in a new tab フィールドを WHERE 節で使用し、リテラル値またはホスト変数と比較する場合は、%Library.FloatOpens in a new tab の適切なメソッドを呼び出すことによって、その値を正規化できます。 ただし、そのフィールドで %Library.FloatOpens in a new tab のサブクラスを使用し、関数 ACOS、ASIN、ATAN、COS、COT、EXP、LOG、LOG10、POWER、SIN、SQRT、TAN、TRUNCATE のいずれか、または算術演算子 (“+”、“-”、“*”、“/”、“\”、および “#”) のいずれかをそのフィールドで使用すると、Caché では、関数に対する引数が ODBC データ型の DOUBLE で、関数が DOUBLE を返す場合を除き、返す必要のある値は数値であると判断されます。

例えば、ABC という名前のプロパティを持つ TEST というクラスがあり、ABC のデータ型が %Library.FloatOpens in a new tab を拡張した User.MyFloat で、User.MyFloat の ODBC データ型が DOUBLE であるとします。 ここで、次の SQL クエリを考えます。

SELECT ABC FROM SQLUser.MyFloat WHERE {fn TRUNCATE(ABC,3)}=.482

ABC の値が .48259 の行が TEST にある場合、リテラル入力 .482 は %Library.DOUBLE の正規化メソッドが適用されて、$DOUBLE(.482) = .48199999999999998401 になるので、この行は検出されません。

Caution:

データ型 %FloatOpens in a new tab を使用するアプリケーションまたは %Library.FloatOpens in a new tab の拡張を使用するアプリケーションでは、データの実際の値に十分配慮する必要があります。 %Library.FloatOpens in a new tab は ODBC に DOUBLE 値を返しますが、データベースには DOUBLE 値を格納しません。

%Library.FloatOpens in a new tab およびこのデータ型の拡張の使用はお勧めできません。クラス %Library.DoubleOpens in a new tab を使用することをお勧めします。

入力値に対する単純な正規化の実行

2009.1 以降、クエリへの入力としてリテラル値またはホスト変数を必要とする SQL 文では、"簡略な正規化" を適用したうえでこれらの値を受け入れるようになりました。例えば、クエリの形式が以下のいずれかであるとします。

  • <field> <operator> <literal>

  • <field> <operator> <host variable>

  • <scalar function> (<literal>)

  • <scalar function> (<host variable>)

ただし、これは ODBC モードおよび実行時モード (またはそのいずれかのモード) であるとします。クエリの処理を開始すると、<literal> または <host variable> には、(項目のデータ型に応じて) 必要な OdbcToLogical 変換または DisplayToLogical 変換が適用されます。この最初の変換 (必要な場合) が適用された後に、以下の手順で "簡略な正規化" が実行されます。

  • 値が NUMERIC または INTEGER であるか、データ型が %Library.FloatOpens in a new tab である場合、Caché では、非 NULL 値に “+” 演算子を使用して値を数値に正規化します。以下のクエリを考えてみます。

    SELECT ... WHERE MyIntegerField = :hVar
    

    このクエリでは、hvar に 'abc' (正規化した +'abc' は 0) のような値を指定すると、MyIntegerField = 0 となる行が返されます。

  • 値のデータ型が DOUBLE の場合、Caché は値を $DOUBLE に変換します (値が NULL ではない場合)。

  • 値のデータ型が TIMESTAMP の場合、Caché は、末尾のスペースを削除します。さらに、値に "." がある場合は、末尾の 0 をすべて削除したうえで、末尾の "." を削除します。 これによって、'2008-06-27 08:15:23.000' は '2008-06-27 08:15:23' に、また、'2008-06-27 08:15:23.120' は '2008-06-27 08:15:23.12' に正規化されます。

SCALE レポートおよび集約の問題の修正

2009.1 以降、AVG を使用して生成した列はデータ型 DECIMAL としてレポートされます。ただし、AVG に対する引数が $DOUBLE 値の場合は、AVG 関数から $DOUBLE 値が返されます。AVG 関数が DECIMAL を返し、AVG に対する引数の有効桁数が p で小数点以下桁数が s である場合、結果の有効桁数は 18 に、小数点以下桁数は 18-p+s になります。AVG 関数が $DOUBLE を返す場合、その列の小数点以下桁数は 0 になります。

複数行を返す際の新しい SQLCODE

今回のバージョンでは、関数からの返り値として単独の値のみを想定している場合に複数の行が返されると、新しい SQLCODE エラー -432 が生成されます。これは現在、Informix 変換コードで使用されているものであり、関数をスカラ関数として呼び出し、返り値として単独の値を想定しているにもかかわらず、プロシージャから複数の行が返されたときにエラーをレポートします。Innformix エラー -686 に相当するエラー・コードです。

日付、時刻、またはタイムスタンプに対して SUM() を使用したときのエラー・レポート

新規のエラー SQLCODE=-379 が導入されています。これは、データ型が DATE、TIME、または TIMESTAMP である引数を持つ SUM 集約関数を使用した SQL 文をアプリケーションで作成しようとしたときにレポートされます。

埋め込み CALL 文で作成する新しい %sqlcontext

埋め込み SQL CALL 文では、その実行時に %sqlcontext 変数に対して NEW コマンドが実行されるようになりました。 %sqlcontext 変数は、この CALL が終了すると削除されます。

Note:

Caché では、埋め込み SQL 文にある CALL 文から結果セットを返り値として取得することはできません。

サブクエリのある INSERT 文のエラー・レポート

Caché では、以下のような INSERT 文にあるサブクエリはサポートされていません。

INSERT INTO Addressee 
   SET LetterId = ? , 
   RelationshipId = ( SELECT id 
                      FROM Dictionary . AddresseeRelationshipToPatient 
                      WHERE code = ? ) , 
   AddresseeIEN = ? , 
   recipientType = ? , 
   Name = ?)

このような場合、以前のバージョンでは、コンパイル時に構文エラーが示されるだけでした。 現在は、クエリの作成やコンパイル時に、サポートされていないことを示すエラーが返されます。 このエラーの SQLCODE 値は -144 で、内容は [INSERT文ではサブクエリは許可されません] です。

SUBSTRING(<LongVarBinary>) の BINARY 型の返り値

データ型が LONGVARBINARY である引数を指定した SUBSTRING() を使用すると、データ型が VARCHAR (%Library.StringOpens in a new tab) ではなく、BINARY (%Library.BinaryOpens in a new tab) である結果が返されるようになりました。

DDL のフィールドに対する照合の指定

DDL の CREATE TABLE 文または ALTER TABLE 文によるフィールドの照合を指定しても、その照合が Caché でサポートされていない場合は、エラーが返されるようになりました。 以前のバージョンでは、CREATE TABLE に対しては、サポートされていない照合名であることが示されていましたが、ALTER TABLE には対応していませんでした。 現在は、CREATE TABLE と ALTER TABLE の両方で、有意なエラー・メッセージが返されます。

また、クラスを定義済みで、DDL を使用して照合を指定している場合、照合プロパティ・パラメータの照合値はすべて大文字になります。

照合の指定がない場合の既定値 EXACT

プロパティに照合 (いわゆる EXACT 照合) を適用しない場合、照合対象のフィールドの添え字情報が %EXACT としてレポートされるようになりました。

OID ではなく OREF となった SQL クエリの返り値

以前のバージョンでは、埋め込み SQL クエリまたは動的 SQL クエリから結果の一部として外部ストリームが返される場合、そのストリームに対する参照が OID (オブジェクト ID、%Library.ObjectIdentityOpens in a new tab) として返されていました。今回のバージョン以降は、このストリーム参照が OREF (オブジェクト参照、%Library.ObjectHandleOpens in a new tab) として返されます。

WARNING:

結果として外部ストリームを返す既存アプリケーションは、新しいデータ型を使用するように変更する必要があります。

SQL の UPDATE 後に変更された末尾区切り文字

区切り文字値がグローバル・ノードの末尾に追加されないようにするため、UPDATE の SQL データ・ファイラが変更されています。これは、区切り識別子付きで %CacheSQLStorage をノードに使用した場合に発生します。例えば、以下のようなノードがあるとします。

^Patient({ID},10) = {Name} ^ {Age} 

SQL の UPDATE を実行すると、このノードが以下のように変更されることがあります。

^Patient({ID},10) = {Name} ^ {Age} ^

これでもこのデータは有効ですが、グローバル・データを直接参照するアプリケーションに影響を及ぼす場合があります。末尾の区切り文字を挟んでテーブルのデータを定義している場合に、SQL によって末尾の区切り文字が追加されます。

SQL ゲートウェイの変更

リンク先テーブルに対する %Library.Double の使用

Caché では、リンク先テーブルの浮動小数点値が %Library.FloatOpens in a new tab ではなく、%Library.DoubleOpens in a new tab で表示されるようになりました。

CSP の変更

HTTPS 使用時に保護されていないチャンネルの CSP 情報の無効化

以前のバージョンでは、Caché がブラウザに送信する CSP sessionId cookie には 'secure' フラグが設定されませんでした。このため、HTTPS CSP アプリケーションの動作に基づいて、名前が同じでも https ではなく http の Web サイトにブラウザが強制的に接続されることがありました。このとき、ブラウザから送信される sessionId cookie はクリア・テキストなので、ネットワークからこのテキストをスニッフィングし、その cookie 情報を使用して元のユーザになりすます操作を防止できませんでした。

バージョン 2009.1 ではセキュリティを強化するために、CSP セッションが HTTPS 要求のみを認識している場合、Caché はセキュリティが保護されたビット・セットでセッション cookie を送信します。CSP セッションが HTTP 要求を認識している場合、セッション cookie はセキュリティが保護されたビット・セットなしで送信されます。つまり、https ページで起動し、http ページに移動する CSP アプリケーションでは、その移動に伴って新しいセッションが開き、ライセンスの取得などが実行されます。これは、sessionId のスニッフィングの防止を意図しています。

ユーザ・アプリケーション側で、暗号化せずに sessionId をネットワーク上に送信できるようにする場合は、以下の 2 つの方法を利用できます。

  1. http ページで起動した後で、https ページにリンクします。こうすることで、sessionId には 'secure' フラグが設定されなくなります。

  2. https ページから http ページにリンクする場合は、プロパティで CSPCHD=<sessionId>、CSPSHARE=1 を設定して sessionId を渡します。

入力時の CSP パラメータの名前と値の変換

以前のバージョンでは、CSP ページが送信されたときに、Caché では、ページの文字セットに応じたパラメータ名の変換が行われませんでした。このため、アプリケーションで非 ASCII 名が使用されていると、%request.Data 配列に正しく表示されませんでした。今回のバージョン以降、Caché では、値と名前の両方が変換されるようになっています。

CSP アプリケーションの静的ファイルの提供の値の変更

CSP アプリケーション /isc/studio/templates および /isc/studio/usertemplates に対してインターシステムズで指定される CSP アプリケーション設定では、静的ファイルの提供のパラメータが “No” から “Always and Cached” に変更されました。 さらにポータルでは、新しいアプリケーションに対して静的ファイルの提供の既定の設定が “No” から “Always” に変更されました。これは、^SECURITY ルーチンの設定と同じです。 現在の CSP アプリケーション設定を確認して、そのアプリケーションの値を “Always” に変更することができます。

Zen の変更

Zen dynaTree コンポーネントの機能向上

このコンポーネントには多数の拡張機能が追加されています。

表示の制御

このコンポーネントでは、フォルダとリーフ・ノードの間に (Windows のツリー・コントロールのように) 線を表示できるようになりました。新たなプロパティ showLines を True に設定することでこの表示が可能になります。このモードでは、ツリー・コントロールで使用するサイズとイメージが 1 種類に固定されます。これが不適切な場合は、showLines を False に設定します。

新しいコールバックによるツリー・コンテンツの提供

新しいコールバックを使用すると、アプリケーションでツリーのコンテンツを取得できます。このコールバックは、OnGetTreeInfo プロパティで設定します。

このコールバック・メソッドは、ツリーのコンテンツ全体を 1 つの配列として返します。この構造は、ツリーのコンテンツをプログラム処理で容易に表示できるようにすることを目的にしています。 この配列の各ノードは、ツリー内の特定のノードに対応します。以下の例のように、各ノードにそのノードに関する情報の $LIST があります。

$LB(caption, value, hasChildren, link, expanded, icon)

以下はその説明です。

  • caption は、ノードに表示するテキストです。

  • value は、ノードの論理値です。

  • hasChildren は、サブノードが存在する場合は 1、存在しない場合は 0 です。

  • link は、ノードをクリックしたときのリンク先となるオプションの URL です。

  • expanded は、ノードに子が存在し、それが表示される場合は 1 です。

  • icon は、ノードに使用するオプション・アイコンの URL です。

ノード構造は、フォームの有向グラフです。

node(0) = $LB(info about this node) 
node(0,"ch",1) = "" // index of first child of this node 
node(0,"ch",2) = "" // index of second child of this node 

遅延ロードのサポート

ノードに子があること (hasChildren=1) がノード構造で示されていても、その子がノードのグラフに表示されていない場合、dynaTree コンポーネントでは、“遅延” ロードがサポートされます。ツリーの初期コンテンツが表示され、子が現在ロードされていないフォルダ・ノードをユーザが展開すると、サーバに対して子のフェッチを求める呼び出しが実行されます。この呼び出しによって、OnGetTreeInfo コールバックが起動し、フォルダ・ノードの論理値が渡されます。

ドラッグのサポート

今回の変更では、dynaTree でのドラッグ操作も可能になっています。

名前のマングリング処理の変更

フォームのブックキーピングを簡素化するため、Zen ではフォームの送信時に使用するコントロールの名前がマングル処理されます。CSP では、"Cache" で始まるコントロール名がログイン関連ページ作成用に予約されています。 今回の変更により、名前が "Cache" で始まるすべてのコントロールがログイン・ページ専用と見なされ、その名前はマングル処理の対象外となりました。

SVG を使用する Zen ページ

SVG を動的にロードする、初期定義に svgFrame を持たないページに必要な処理があります。

<page ... useSVG="true">

このようなページのページ定義には上記の記述を追加する必要があります。これを記述しないと、Javascript エラーが発生します。Zen では、SVG の Javascript コードが既定ではロードされなくなりました。

radioSet コンポーネントおよび radioButton コンポーネントの変更

radioSet コンポーネントおよび radioButton コンポーネントに次の変更が加えられました。

  • 無効にすると、キャプションのスタイルが変わるようになりました。

  • SQL クエリに基づく radioSet により、キャプションに変更が適切に適用されるようになりました。

  • radioButton のキャプションも、radioSet と同じように動作します。

この変更では、新しい CSS クラスを導入してこれらのコンポーネントに適用し、キャプションの無効状態を表現しています。この CSS クラスは、“a.radioSetCaptionDisabled” および “a.radioButtonCaptionDisabled” です。radioButton キャプションのスタイルも、radioSet との整合および “:hover” セレクタのサポートのために、“span.radioButtonCaption” から “a.radioButtonCaption” に変更されています。

したがって、このコンポーネントの captionClass をオーバーライドするアプリケーションでは、次のような CSS スタイル情報の追加が必要になることがあります。

color: none;
text-decoration: none; 
dynaGrid のフォーカスの変更

dynaGrid 内の編集コントロールがフォーカスを取得した場合または失った場合は、onselectcell イベントが発生します。これにより別のイベントが発生することもあります。この場合に、Zen によるイベントが発生することはなくなりました。dynaGrid のサブクラスを定義し、この動作に依存するアプリケーションでは、修正が必要な場合があります。

Zen のクライアント側メニュー・ページ要素に対するキーボード・ショートカットおよびコンテキスト・キーの無効化

Safari および Firefox 3 で行われたキーボード処理の変更により、csMenu サブシステムに組み込まれているキーボード・ショートカット・メカニズムが事実上使用できなくなりました。これにより、これらのプラットフォーム上の textBox コンポーネントおよび textArea コンポーネントと csMenus との互換性がなくなりました。

csMenu サブシステムのユーティリティの一部を暫定的に維持するために、クロスプラットフォーム・ソリューション (または、Apple および Mozilla 側のバグ修正) が実現するまで、キーボード・ハンドラは無効になっています。そのため、開いているメニューを閉じる ESC キーなど、すべてのキーボード・ショートカットが、Internet Explorer と Chrome でも同様に無効になっています。また、この同じキーボード・エンジンを多用する csComboBox ページ要素も、同様に無効です。

Zen レポートの変更

幅を指定していないテーブルまたは新しい defaultWidth 属性

以前のバージョンの場合、幅を指定していない Zen レポートでは自動的に proportional-column-width(1) が指定されていました。 実際には column-width 属性を指定しないことが必要なアプリケーションでは、この措置が望ましくない場合があります。今回のバージョンでは、アプリケーション側で width="none" を指定すると、幅の属性は指定されなくなりました。また、この変更では、新しいテーブル属性である defaultWidth も定義されています。この属性は、幅の指定がない場合に適用する既定の幅の現在の値を無効にし、アプリケーション側で指定する値に置き換えるために使用します。アプリケーションで “none” を指定すれば、column-width 属性は生成されません。

Zen レポートおよびテーブルの特権

今回のバージョンでは、アプリケーションを UnknownUser として実行していて、なんらかの操作を行う特権を持っていない場合でも、Zen レポートを使用して、PDF、HTML、またはテキストでレポートを作成できます。これにより、以前は (実行および出力の特権がないために) 見ることができなかった情報を確認できるようになります。

ZEN レポートの作成者は、オペレーティング・システム・コマンドを実行する特権の有無に依存して情報を保護することができなくなりました。代わりに、テーブルにある機密性の高い情報は、ユーザ・セキュリティまたは適切な保護機能を持つ CSP アプリケーションの実行によって保護する必要があります。ユーザは、SQL 特権を使用して、ZEN レポートの情報の取得元となるテーブル、結果セット、またはストアド・プロシージャを保護することが求められます。 アプリケーションにテーブルを表示する権限がある場合は、そのテーブルから XML を生成してレポートを作成できます。

要素の処理の再定義

グループで処理する ResultSet の行ごとに、要素がグループ内で 1 回表示されるように、要素生成の仕様が定義されました。これにより、必要な要素が 1 つのみであるアプリケーションは失敗する可能性があります。また、同じ要素が複数存在する場合でも、グループによって処理される要素は ResultSet の行ごとに 1 つのみです。"SELECT DISTINCT" または結果セットの生成機能にある他のメカニズムを使用して、どのような場合でも同じ要素が複数存在しないようにすることが可能です。

個々の余白設定より優先する Null 以外の余白設定

今回のバージョンでは、margin 設定が NULL 以外の場合、marginTopmarginBottommarginLeft、および marginRight の値は無視されます。

カスタム集約の定義の変更

カスタム集約の Var および StDev が、不偏推定量として MDX (つまり、n-1 で除算 (n は集団の大きさ)) に対応するようになりました。新しいバイアス推定量 (n で除算) は、VarP および StDevP です。

大きなレポートのコンパイルの失敗

このバージョンでは、非常に複雑なレポートの定義があると、生成されるコードが 32 K の文字を超えてしまい、コンパイルに失敗する場合があります。そのような場合には、インターシステムズのサポート窓口Opens in a new tabにお問い合わせください。

Web サービスの変更

SOAP クライアント・ウィザード — 複数の返り値

複数の値を返すメソッドが、Output パラメータを明示的に持つものとして表されるようになりました。この変更は、オプションのパラメータがない場合の処理に必要です。以前のバージョンでは、最初に返される値がメソッドの返り値として間違って割り当てられていました。

xDBC の変更

より多くのカタログ・クエリを対象とした特権チェック

以下のカタログ・クエリを呼び出す際に特権のチェックが適用されるようになり、ユーザがテーブルまたはビューに対する特権を持たない場合は、カタログ・メタデータが返されません。

ODBC JDBC
SQLSpecialColumns (SQL_BEST_ROWID=1) getBestRowIdentifier()
SQLForeignKeys (Cross Reference) getCrossReference()
SQLForeignKeys (エクスポートされたキー) getExportedKeys()
SQLForeignKeys (インポートされたキー) getImportedKeys()
SQLPrimaryKeys getIndexInfo()
SQLStatistics getPrimaryKeys()
数値および式の有効桁数と小数点以下桁数の向上

xDBC によって SQL 文を作成する場合に、次の前提が適用されるようになりました。

数値リテラル

xDBC を使用して作成した SQL 文でリテラル数値を指定している場合、その値はホスト変数に置き換えられます (ただし、((val)) で囲んでいる場合を除きます)。 その変数の型は NUMERIC で、長さは 20、有効桁数は 18、小数点以下桁数は 9 です。 異なる型、有効桁数、または小数点以下桁数が必要な場合は、SQL 文で CAST を使用します。

加算と減算

引数のいずれかまたは両方が double 型でない限り、得られる式の型は NUMERIC になります (double 型の場合は DOUBLE)。 型が NUMERIC の場合、値の精度は次のようになります。

  • 有効桁数は次のように決まります。

    max(scale1, scale2) + max(precision1-scale1, precision2-scale2) + 1

  • また、小数点以下桁数は次のように決まります。

    max(scale1, scale2)

乗算

引数のいずれかまたは両方が double 型でない限り、結果の型は NUMERIC になります (double 型の場合は DOUBLE)。 型が NUMERIC の場合、値の精度は次のようになります。

  • 有効桁数は次のように決まります。

    min(18, precision1 + precision2 + 1)

  • また、小数点以下桁数は次のように決まります。

    min(17, scale1 + scale2)

除算

引数のいずれかまたは両方が double 型でない限り、結果の型は NUMERIC になります (double 型の場合は DOUBLE)。 型が NUMERIC の場合、値の精度は次のようになります。

  • 有効桁数は次のように決まります。

    min(18, precision1 - scale1 + scale2 + max(6, scale1 + precision2 + 1))

  • また、小数点以下桁数は次のように決まります。

    min(17, max(6, scale1 + precision2 + 1)))

返り値としての ODBC 3.5 カタログ・メタデータ

バージョン 2009.1 以降、ODBC カタログ・クエリは ODBC 3.5 をサポートするように更新されました。これには、次の関係を意味しています(アプリケーションは列番号によって結合するため、列名の変更による下位互換性への影響はありません)。

メタデータ・テーブル名 ODBC 2.0 ODBC 3.x
SQLSpecialColumns PRECISION COLUMN_SIZE
SQLSpecialColumns LENGTH BUFFER_LENGTH
SQLSpecialColumns SCALE DECIMAL_DIGITS
SQLTables TABLE_QUALIFIER TABLE_CAT
SQLTables TABLE_OWNER TABLE_SCHEM
SQLColumns TABLE_QUALIFIER TABLE_CAT
SQLColumns TABLE_OWNER TABLE_SCHEME
SQLColumns PRECISION COLUMN_SIZE
SQLColumns LENGTH BUFFER_LENGTH
SQLColumns SCALE DECIMAL_DIGITS
SQLColumns RADIX NUM_PREC_RADIX
SQLColumns <none> COLUMN_DEF
SQLColumns <none> SQL_DATA_TYPE
SQLColumns <none> SQL_DATETIME_SUB
SQLColumns <none> CHAR_OCTET_LENGTH
SQLColumns <none> ORDINAL_POSITION
SQLColumns <none> IS_NULLABLE
SQLColumnPrivileges TABLE_QUALIFIER TABLE_CAT
SQLColumnPrivileges TABLE_OWNER TABLE_SCHEM
SQLForeignKeys PKTABLE_QUALIFIER PKTABLE_CAT
SQLForeignKeys PKTABLE_OWNER PKTABLE_SCHEM
SQLForeignKeys FKTABLE_QUALIFIER FKTABLE_CAT
SQLForeignKeys FKTABLE_OWNER FKTABLE_SCHEM
SQLForeignKeys <none> DEFERRABILITY
SQLProcedureColumns PROCEDURE_QUALIFIER PROCEDURE_CAT
SQLProcedureColumns PROCEDURE_OWNER PROCEDURE_SCHEME
SQLProcedureColumns PRECISION COLUMN_SIZE
SQLProcedureColumns LENGTH BUFFER_LENGTH
SQLProcedureColumns SCALE DECIMAL_DIGITS
SQLProcedureColumns RADIX NUM_PREC_RADIX
SQLProcedureColumns <none> COLUMN_DEF
SQLProcedureColumns <none> SQL_DATA_TYPE
SQLProcedureColumns <none> SQL_DATETIME_SUB
SQLProcedureColumns <none> CHAR_OCTET_LENGTH
SQLProcedureColumns <none> ORDINAL_POSITION
SQLProcedureColumns <none> IS_NULLABLE
SQLPrimaryKeys TABLE_QUALIFIER TABLE_CAT
SQLPrimaryKeys TABLE_OWNER TABLE_SCHEM
SQLProcedures PROCEDURE_QUALIFIER PROCEDURE_CAT
SQLProcedures PROCEDURE_OWNER PROCEDURE_SCHEM
SQLStatistics TABLE_QUALIFIER TABLE_CAT
SQLStatistics TABLE_OWNER TABLE_SCHEM
SQLStatistics SEQ_IN_INDEX ORDINAL_POSITION
SQLStatistics COLLATION ASC_OR_DESC
SQLTablePrivilges TABLE_QUALIFIER TABLE_CAT
SQLTablePrivilges TABLE_OWNER TABLE_SCHEM
SQLGetTypeInfo PRECISION COLUMN_SIZE
SQLGetTypeInfo MONEY FIXED_PREC_SCALE
SQLGetTypeInfo AUTO_INCREMENT AUTO_UNIQUE_VALUE
SQLGetTypeInfo <none> SQL_DATA_TYPE
SQLGetTypeInfo <none> SQL_DATETIME_SUB
SQLGetTypeInfo <none> NUM_PREC_RADIX
SQLGetTypeInfo <none> INTERVAL_PRECISION
getColumns カタログ・クエリへの IS_AUTOINCREMENT 列の追加

JDBC DatabaseMetaData メソッドの getColumns() は、タイトルが IS_AUTOINCREMENT である 23 番目の列を返すようになりました。 INSERT 時に自動的にインクリメントされる列である場合、この列は YES を返し、そうでない場合は NO を返します。

クエリの返り値の変更

このバージョンの Caché では、%SQLGatewayConnection.Fetch() に対して必ず値が返されます。ただし、すべてのデータが使用済みの場合の値 100 は返されなくなりました。これを確認するには、アプリケーション側から SQLCODE の値を調べる必要があります。

SQL_TIMESTAMP の秒の小数部先頭のゼロの保持

SQL_TIMESTAMP 構造の小数部は、ナノ秒の数値を表す整数です。以前のバージョンでは、小数部の先頭に “0” があり、その後に数字が続く場合に、ODBC ドライバで変換上の問題が発生していました。以下はその例です。

2008-02-02 12:23:45.0012

この場合、以下のように変換されていました。

2008-02-02 12:23:45.12

バージョン 2009.1 では、このエラーが修正されています。

JDK1.4 の非推奨

今回のリリース以降、JDK 1.4 は非推奨になりました。これは、有料の延長契約を除き、Sun により正式にサポート対象外になりました ("END OF SERVICE LIFEOpens in a new tab")。 JDK 1.4 で開発されたライブラリ (JAR ファイル) は、多くの場合、JDK 1.5 以降でも問題なく実行できます。 JDK 1.4 のサポートは、Caché 2010.x に終了します。

インターシステムズの現在の計画では、Java の新製品はすべて JDK 1.6 で開発される予定です。 現在の機能 (および後続のバグ修正版) では、JDK 1.5 がサポートされます。上記のポリシーによると、JDK 1.5 は 2009 年 10 月 30 日にサービスを終了しています。 インターシステムズでは、この日付から最低 1 年間は JDK 1.5 のサポートを継続する予定です。

一般的に、インターシステムズでは JDK の各バージョンのサポートを、サービスの終了日付から最低 1 年間は継続します。 これにより製品の機能が強化され、仮想マシンの安定性および速度が向上します。

MultiValue の変更

MVBasic の MATWRITE 文および MATREAD 文とトリガ

ファイルに対して定義している MATREAD 文および MATWRITE 文では、適切なトリガが呼び出されるようになりました。以前のバージョンでは、トリガは無視されていました。

SYSTEM(11) の変更

SYSTEM(11) では、Pick、Information、PIOpen、IN2、および Universe のエミュレーションに既定の select リストが存在するかどうかを示すブーリアン・フラグが返されるようになりました。以前のバージョンでは、リスト内のアイテムの数が返されていました。以前の (誤った) 実装に依存しているアプリケーションでは、リストの数を取得する別のメソッドに変更する必要があります。

SYSTEM(49) によって報告される行番号の変更

以前のバージョンの Cachéでは、SYSTEM(49) によって報告される行番号は、ソース (MVB) ルーチンではなく中間 (MVI) ルーチンを基準としていました。 今回のバージョンで、ソースの行番号が適切に表示されるようになっています。 また以前は、ルーチンの実行中にルーチンをリコンパイルすると、<SUBSCRIPT> エラーが発生していました。 今後の SYSTEM(49) では、実際のソース行を特定できない場合、行番号は 0 としてレポートされます。

ポート番号による WHERE コマンドの並べ替え

WHERE コマンドの出力が、既定でポート番号によって並べ替えられるようになりました。これにより、Caché と LISTU や WHO などの他のコマンドとの間で整合性が得られます。さらに、Caché のジョブ番号に基づく並べ替えと選択が可能な新しい (D) オプションが WHERE コマンドに追加されました。(D) オプションを使用すると、選択基準が MV ポート番号ではなく Caché のジョブ番号になります。

MultiValue の INPUT 文および IN 文のエコーとプロンプトの修正

バージョン 2009.1 以降の Caché では、INPUTINPUT @IN、および KEYIN の各関数について、エコーの方法、エコー出力デバイス、およびサポートするプロンプト (PROMPT 文) に関する以下の規則に従います。

  1. どのようなエコーでも、出力先はプリンタではなく画面のみです。

  2. PROMPT 文で定義されるプロンプト文字列は、必ず INPUT および INPUT @ 文で使用されます。このプロンプト文字列はプリンタではなく画面にのみ出力されます。

  3. エコーが無効になっている場合、 INPUT @ 文はエミュレーションに依存する必要があります。プラットフォーム・エミュレーションの中には、Cache や Universe のように、エコーが無効になっていても INPUT @ で文字をエコー出力するものがあります。一方、その他のプラットフォーム・エミュレーション (jBASE や D3 など) は、エコーの状態に従う必要があります。

  4. エコーが有効になっている場合、KEYIN 文および IN 文はエミュレーションに依存します。エミュレーションには、エコーの設定に従うものと、文字をエコー出力しないものとがあります。

MultiValue の一部のエミュレーションでのページ付けの廃止

バージョン 2009.1 以降、MultiValue エミュレーションの中には、出力へのページ付けが既定では行われなくなるものがあります。それらのエミュレーションにおいて、ページ付けされた出力を必要とするアプリケーションでは、SP.CONDUCT コマンドを使用して明示的にページ付けを有効にする必要があります。現在のところ、既定で出力にページ付けが行われるのは、Cache、Universe、および Unidata の各エミュレーションのみです。

新しい関数の追加

MVBasic に、LISTVALID 関数および LISTNEXT 関数が追加されました。これらの意味は、それぞれ ObjectScript 関数の $LISTVALID および $LISTNEXT と同じです。これらの識別子のいずれかを変数として使用するアプリケーションは、名前が重複しないように編集する必要があります。

Open トリガの呼び出しの廃止

トリガ・ルーチンのエラーによってトリガ・コマンドが実行できない場合があるため、トリガ・コマンドによる OPEN トリガの呼び出しは廃止されました。

OCONV での日付の小数部切り捨てによる整数化

以前のバージョンでは、日付の小数部の OCONV で変換が行われず、代わりに元の値が返される場合がありました。 今回のバージョンでは、変換前に必ず小数部が切り捨てられて整数になります。

select リストとエミュレーションの正確な一致

PROC P コマンドでは、エミュレーション・モードに応じて、アクティブな select リストが次のように適切に保持または破棄されるようになりました。

  • Cache、UniVerse、PICK、Prime、IN2、PIOPEN、および Unidata の各エミュレーションでは、MVBASIC プログラム、TCL コマンド、およびクエリの実行後にアクティブな select リストが保持されます。

  • その他のエミュレーション (特に jBASE、D3、R83、および REALITY) では、MVBASIC プログラムの実行後にアクティブな select リストが保持されなくなります。

空のリスト変数を処理するための READNEXT の修正

以前のバージョンでは、空のリスト変数から READNEXT を実行すると、エラーとして処理されず、既定のリスト 0 から読み取りが行われていました。今回のリリース以降、READNEXT では "" が存在するかどうかがチェックされ、存在する場合は無効な OREF として処理され、STATUS() = -2 が設定されます。

空文字列のインデックス検索の変更

以前のバージョンで CACHE エミュレーションを使用すると、以下の式

INDEX(string, "" ,1)

では 0 が返されました。今回のバージョンでは、正しい値である 1 が返されるようになりました。

MultiValue でない配列に対する MATREAD からのエラーの発行

MATREAD では、アプリケーションが MultiValue でない入力からの読み取りを試みると、エラーが発行されるようになりました。以前のバージョンでは、MATREAD によって ELSE 節が実行されていました。また、MultiValue 配列を要求する処理で MultiValue でない配列が使用されている場合に、よりわかりやすいエラー・コードが発行されるように MATREAD が変更されました。

READ 設定の変更

Ultimate エミュレーションの READV0 の既定の設定が、RV0.KEY から RV0.EXISTS に変更されました。 READ.RETAIN の既定の設定が、Information エミュレーションでは無効、PIOpen エミュレーションでは無効、Ultimate エミュレーションでは有効に変更されました。

SPOOLER の見出し処理の変更

今回のバージョンでは、HEADING 文と FOOTING 文で多くの変更が行われ、それに伴って一般的なプリンタ出力やターミナル出力にも変更が加えられました。スプールした出力の形式に依存するアプリケーションでは、この変更後も実際の出力と想定した出力が一致するかどうかを慎重に確認する必要があります。

スプーラのジョブ番号の日次リセット

以前のバージョンでは、MultiValue スプーラの印刷ジョブに割り当てられたジョブ番号がリセットされませんでした。このため、数週間後や数か月後にはその値が非常に大きくなり、管理を困難にしていました。今回のバージョンでは、ジョブ番号が毎日リセットされます。既存のジョブが上書きされないようにチェックも行われます。例えば、ジョブ 1 が既に存在する場合はジョブ番号 2 を使用し、ジョブ 2 が存在する場合はジョブ番号 3 を使用するという方法で、順次大きいジョブ番号を使用します。ただし、アプリケーションからはジョブ番号を予測できなくなります。

MVASSOCIATION が存在する場合の SQLTABLENAME および SQLPROJECTION の無視

SQLPROJECTION は、SQL に対するコレクションの既定のプロジェクションを定義します。MVENABLED クラスで、次の式を考えてみます。

SQLPROJECTION = TABLE

この式は、子テーブルが列と同様に投影されることを示します。 SQLTABLENAME プロパティは、そのテーブルの名前を定義します。

MVASSOCIATION を使用すると、MVENABLED クラスにあるプロパティで、複数のコレクションを 1 つの SQL 子テーブルを形成するものとして定義できます。MVASSOCIATION を定義しているプロパティがある場合、SQLPROJECTION および SQLTABLENAME は無視され、関連付けられたプロパティによって投影される子テーブルの名前として MVASSOCIATION の値が使用されます。

この変更によって、MVASSOCIATION によって投影される SQL テーブルの名前が変更されます。以前のバージョンでは、MVASSOCIATION を使用すると、ユーザが予期しない誤った動作が発生していました。場合によっては、MultiValue のユーザは、新しい (正しい) テーブル名を認識するようにアプリケーションの適合を図る必要があります。

Jalapeño の変更

NetBeans 5.5 プラグインの廃止

Jalapeño は現在、バージョン 6.0 の NetBeans プラグイン用にのみビルドされています (5.5 と 6.0 の両方ではありません)。

コンパイル済みクラス・テーブルへのアクセスに必要な Select 特権

Jalapeño では、指定されたクラスのすべての既知のサブクラスを調べて、使用するインスタンスを決定するようになりました。これらの検索には %Dictionary.CompiledClass テーブルを使用します。したがって、処理を正常に実行するには、ユーザにこのテーブルに対する SELECT 特権が必要です。

一意でないクライアント名に対する例外の生成

いくつかの Caché クラスでは、クライアント名を使用して Java クラスを参照することがあります。その場合、Jalapeño オブジェクト・マネージャでは、それらの Caché クラスのうち、どのクラスを使用すべきかを判断できません。以前のバージョンでは、クエリによって最初に返されたクラスを使用していました。今回のバージョンでは、1 つのクラスのみが条件を満たすことを確認し、それ以外の場合はエラーを返します。

オブジェクトの保存アルゴリズムの変更

今回のバージョンでは、Jalapeño を使用して 1 回のメソッド呼び出しで複数のオブジェクトを保存する方法が変更されました。オブジェクト間の依存関係を解決するロジックの大半が、Caché サーバから Java クライアントに移動しています。新しい保存の実装は従来のものと機能的には同等ですが、より多くのロジックが Java クライアントに移動しているので、動作上の変化 (タイミングの変化など) が現れる可能性があります。

特に、この変更以前は、保存するオブジェクトにコレクションが存在する場合、そのコレクションの型が必ず保持されていました。新しいアルゴリズムでは、保存を最適化するためにこれが変更されており、ArrayList が LazyList に置き換えられる場合があります。

スキーマ・ビルダによる配列のさまざまな処理

今回のバージョンでは、基本配列である一部の Java プロパティに対するスキーマ・ビルダの動作が変更されました。Java で、以下のいずれかの配列があるとします。

byte [] SomeBytes;
char [] SomeChars;
int [] WholeNumbers;

既定では、このようなプロパティは Caché コレクションとして投影されますが、これは通常望ましい選択ではありません。これらのプロパティに以下のようなアノテーションを付けると、状況はさらに悪化します。

@CacheProperty(type = "%CacheString")

これらのプロパティは %CacheString のリストとして投影されていました。今回のバージョンでは、基本配列がどのように投影されるかが以下のルールによって決まります。

  1. アノテーションを付けない場合は、基本タイプのコレクションとして投影されます。これは、以前のバージョンと同じです。

  2. 次のアノテーションを付けた場合は、指定されたタイプの単一のプロパティとして投影されます。

    @CacheProperty(type = "...")

    この場合、@Collection としても、また @Lob としてもアノテーションを付けていないことが必要です。これは、以前のバージョンとは異なります。

  3. 次のアノテーションを付けた場合は、指定されたタイプのコレクションとして投影されます (変更なし)。

    @Collection(type = CollectionType.LIST)@CacheProperty(type = "...")

    これは、以前のバージョンと同じです。

  4. 次のアノテーションを付けた場合は、%Stream として投影されます。

    @Lob (type in @CacheProperty ignored)

    これは、以前のバージョンと同じです。

ソース・コントロールの変更

%Project のグローバルな名前変更

このバージョンより古い Studio では、現在アクティブな %Studio.Project のコピーを保持するためにパブリック変数 %Project を使用していました。そのため、Studio でプロジェクトを削除しても、オブジェクトを正しく閉じることができませんでした。このバージョン以降では、現在のプロジェクト名がプロセス・プライベート・グローバル ^||%Studio.Project に保存されます。このオブジェクトに関するデータを必要とする関数では、この新しい場所を使用する必要があります。

プラットフォーム固有の項目

このセクションでは、特定のプラットフォームに関係する項目について説明します。

Unicode システムにおける Raw から UTF8 への既定の Telnet 変換の変更

次のロケールでは、Telnet (“その他のターミナル”) の既定の変換が RAW から UTF8 に変更されました。

  • araw

  • csyw

  • danw、deuw

  • ellw、engw、enuw、espw、eurw

  • finw、fraw

  • hebw、hunw

  • itaw

  • ltuw

  • nldw

  • plkw、ptbw

  • rusw

  • thaw

この既定値が作成された当時は、UTF-8 をサポートするエミュレータはほとんど存在しなかったため、RAW の使用が妥当でした。現在では、大半のエミュレータが UTF-8 を既定でサポートしています。 さらに、Latin1 に基づかないロケール (araw、csyw、ellw、hebw、hunw、ltuw、plkw、rusw、thaw など) では、非 ASCII 文字で不具合が発生していました。これらの文字は、RAW のサポート範囲外の文字なので "?" に変換されていました。また、上記リストで Latin1 に基づくロケール (deuw、enuw、ptbw など) でも、文字の値が 255 を超えるユーロ記号については、RAW を使用した telnet で処理できませんでした。

UTF-8 には、ASCII. との完全な互換性があります。つまり、ASCII のみを使用する言語のロケール (英語など) では、変化を認識することはありません。Latin1 に基づくロケールのうち、128 ~ 255 の値を持つ文字を使用するロケールのユーザは、アクセント記号付きの文字が正確に処理されるように、telnet クライアント・プログラムで使用しているエンコードを UTF-8 に変更することが必要になる可能性があります。

Unicode システムから得られるターミナル・ログ・ファイルの Unicode 化

バージョン 2009.1 以降、ターミナルで作成されるログ・ファイルは、8 ビット・インストール環境では ANSI、Unicode インストール環境では Unicode としてエンコードされるようになります。

ビッグ・エンディアン・システム上の $LISTSAME

以前のバージョンにある $LISTSAME() 関数では、2 つのリストを比較したとき、一方のリストにある整数が、他方のリストの対応する位置に表現の異なる (文字列や浮動小数値など) 同じ整数として存在している場合、この 2 つのリストが等しくないとレポートされることがありました。この不具合はビッグ・エンディアン・プラットフォームでのみ発生していました。

MQ コンテキストの変更

以前のバージョンの Caché では、無条件に Context が 2 (SET_ALL_CONTEXT) に設定されました。 この動作により、MQ の使用時に承認エラーが発生していました。

今回のバージョンでは、MQ Put 接続 (Net.MQSend) 用に Context というフラグが定義されました。 この Context フラグの値は次のとおりです。

  • 0 : 既定。

  • 1 : ID。アプリケーションは、ID による Context を使用して ApplIdentityData フィールドを設定し、渡します。

  • 2 : すべてのコンテキスト。この Context によって、ApplIdentifyData フィールドおよび PutApplType フィールドを設定して渡すことができます。

コンテキストを ID (1) またはすべて (2) に設定すると、承認への影響が発生する場合があります。 以前はエラーが発生しなかったアプリケーションでも、処理に失敗して MQ 承認エラー (2035) が発生するようになる可能性があります。 詳細は、IBM Websphere MQ のドキュメントを参照してください。

OpenVMS ストリーム・レコード・サイズの増加

Caché を使用することで、OpenVMS 上で動作しているアプリケーションでは、ストリーム・モードで最大長 32,767 バイトのレコードを OpenVMS 上で作成できるようになりました。このレコード長は、OpenVMS RMS シーケンシャル・ファイルで許容される最大サイズです。この長さには、レコードを終端する CR/LF の長さも考慮します。以前のバージョンの Caché では、163853 より長いレコードの書き込み要求は、暗黙的にシーケンシャル・ファイル内で 2 つ以上のレコードに分割することによって処理していました。この変更により、32,767 バイトの制限を超えると <WRITE> エラーがレポートされるので、アプリケーションでは、最大レコード・サイズを超えたことを明確に把握でき、無意識に複数のレコードを作成することがなくなります。

64 ビット・システムでの比較の修正

Caché バージョン 2008.2 では、ほぼ等しい数値どうしの浮動小数点比較で矛盾が発生していましたが、今回のバージョンで修正されています。10 進値に丸めた $DOUBLE 値を 20 桁に拡張した値が Cache の 10 進値と等しいときに、この $DOUBLE 値と Cache の 10進値どうしを比較したときにこの問題が発生していました。 この場合、$DOUBLE 値を Cache の 10 進値と比較すると、3 種類のすべての比較演算 (より小さい、等しい、より大きい) が False となります。今回のバージョンでは、これらの比較演算で必ず 1 つ以上の関係が True となります。

Visual Studio 2008 を使用した Windows インタフェースの構築

バージョン 2009.1 では、Microsoft Visual Studio 2008 を使用してその Windows コンポーネントを構築しています。C、C++、CallIn、または CallOut を使用するアプリケーションも、Visual Studio のこのバージョンを使用して構築する必要があります。SAMPLES ネームスペース内の Windows サンプルも、このバージョンを使用して構築されました。

Windows インストール環境での小文字のディレクトリ名の使用

Caché では、インストール・ディレクトリの名前に小文字を使用するようになりました。以前のバージョンでは、例えば \Bin ディレクトリにインストールされていました。バージョン 2009.1 では、これが \bin になります。

オペレータ

システム管理ポータル

2007.1 のリリース以降、システム管理ポータルに数多くの変更や改善が加えられました。詳細は、管理者のセクションを参照してください。

FeedbackOpens in a new tab