ご使用のアプリケーションで、この違いを認識するため、各変更に関する解説では修正点が詳細に説明されています。

すべての変更には、発生する可能性のある問題、変更による衝突、および他のカスタマによってこれが無事に使用されているかなどに関する永続的な情報を提供する表が含まれます。 この情報を簡単に理解することができるように、テーブル形式の情報は 1 つ、または 2 つのキーワードと値に簡素化されています。 キーワードの意味は、以下の通りです。

• 可能性 - 関連するプラットフォームのユーザが、この問題に出会う可能性

• 危険性 - この変更がアプリケーション環境に新たな問題を誘発する可能性

• 仮リリース - これは、この変更が試験的なリリースで以前に導入されたことがあるか、またカスタマが製品を無事に使用できているかを示します。

• 拡張性 - これは、この変更が新機能や拡張機能を提供するかを示します。

このセクションのリファレンスを慎重に検証してください。

これは、システム参照カウントがゼロになってもオブジェクトがアクティブであるという、オブジェクト参照カウントの問題を修正しています。 この問題は、オブジェクト参照が %String や %Integer などの非オブジェクト・データ型として宣言されているオブジェクト・プロパティに保存されているときに発生していました。

アプリケーション・エラー

従来は、お互いにリレーションシップを持つ 2 つのオブジェクトと、そのオブジェクトの 1 つがリレーションシップの片側を削除するために変更された場合、この削除によってディスクの繁殖は失敗することがありました。 それにより、参照されたオブジェクトがリレーションシップでその後も存在するという結果になっていました。

これは、"cardinality = many" と "cardinality = children" で修正されています。 エラーは現在でも、1:1 と M:N のリレーションシップで発生する危険性があります。

アプリケーション・エラー

OpenVMS 上で共有メモリ・セクション名を生成するメソッドは、複数の処理が同じプロセス名を持つことを OpenVMS が許可したときに発生する問題を回避するために変更されました。 従来のメソッドは、Caché の他のインスタンスが起動しているかを検出するために、プロセス名で衝突を使用していました。 この変更により発生する制限は、Caché がインストール (例えば、マネージャ・ディレクトリが存在する場所など) されているデバイス名は 16 バイト以下である必要があるということです (末尾の ":" は除きますが、先頭の "_" は含まれます)。 これは、すべてのサイトに対して問題を引き起こすことはありませんが、Caché はこの場合、エラー・メッセージが表示された後の起動は行いません。

製品の停止

この Caché メンテナンス・キットには、Windows プラットフォーム上の特定のテープ・デバイスに対するパフォーマンスが著しく向上する、バックアップ・ユーティリティでの修正が含まれます。 しかしこれによって、Caché が以前のメンテナンス・キットやバージョンからバックアップを読み込むことができなくなることもあります。

DLT4 などのテープ・ドライブでは、バックアップ・ブロックはより小規模な一連のブロックとして書き出されていました。 今回の修正では、連続した単独ブロックが記述されていることを明確にすることでパフォーマンスは著しく向上しています。しかし、この修正以前に同じハードウェアで生成されたバックアップは、今回の Cache の修正バージョンでリストアできません。

バックアップの実行が低速になります。

2.1GHz、またはそれより高速なプロセッサ搭載の Windows 上で、$ZHorolog 特殊変数が負の値を返す結果となるバグは修正されています。

$ZHOROLOG は通常、内部アプリケーションのタイミングで使用されます。 これが、製品アプリケーションに影響を与える可能性は低いです。

抽象クラスとしてクラスを定義する場合、Caché は現在、クラス・メソッドと同様にすべてのインスタンス・メソッドを作成することができます。 従来は、クラス・メソッドのみを生成していました。 Caché がサブクラスから ###super を使用してこれらのメソッドを呼び出すことができるように、インスタンス・メソッドが必要とされています。

##super は現在、抽象スーパークラスと共に機能しています。

Caché 4.1.9 で適切にロードされ、コンパイルされていた特定の CDL ファイルが、Caché 5.0.1 ではコンパイルに失敗していました。 これは、テーブル・コンパイラが行の最後に "=" を追加したためです。これは、今回のバージョンで修正されました。

コンパイルされなかった CDL ファイルも、現在はコンパイル可能です。

Cache 4.x では、以下の構文を使用したデータ型クラスのクラス・メソッドの呼び出しは有効でした。

   Write ##class(=datatype).Method(args)

しかし Caché 5.0 では、"Not Found" エラーを引き起こしていました。 これは、インターシステムズがシステム・レベルでこの構文をサポートし、システム・コードが呼び出す場所を検索できるようにするクラス記述子が、データ型クラスに対して生成されなかったためです。 現在、クラス記述子はデータ型クラスに対して生成されるので、ユーザはこれらのクラス・メソッドを呼び出すことができます。

データ型クラスのクラス・メソッドを呼び出すことは、このデータ型をプロパティの型として使用するときに生成されたメソッドの呼び出しとは異なることに注意してください。これは、異なる一連のパラメータを持っているからです。 例えばクラスのプロパティとして、文字列が最大長 50 文字であることを指定した場合でも、データ型クラス自体は、デフォルトで最大長 100 に設定されています。 このデータ型クラスを直接呼び出すとき、これが異なるコンテキストであることに注意する必要があります。

アプリケーション・エラー

入れ子になった連続した列は、そのプロパティも SQL に投影されている場合は非表示にされます。 このロジックはシリアル・プロパティ・プロジェクタに存在していましたが、プロセスでの 'hidden' フラグの設定は遅すぎました。 現在は、連続した列のプロジェクションが避けられるとき、適切に決定されます。

少 ; 入れ子にされたシリアル・オブジェクトのプロジェクションは、新機能です。

空のエレメント値 (<tag/>) を文字ストリーム・プロパティに保存するとき、現在は "" を $c(0) ではなくストリーム・オブジェクトに保存しています。 エレメントが存在しないときは、ストリーム・エレメントを保存しません。

空ストリームは現在、改善された方法で XML にエクスポートされます。

シリアル・オブジェクトのすべての値が "" である場合、XMLExport は参照を処理するためにシリアル・オブジェクトに変換されていました。 値セットを持たないシリアル・オブジェクトは現在、タグなしでエクスポートされます。 これは、NULL オブジェクトに対して SQL テストを使用します。

シリアル (埋め込み) オブジェクトは、そのオブジェクトが NULL の場合 (つまり、そのすべてのフィールドが空欄の場合) は XML プロジェクションに含まれません。

クラスタ・マスタ以外のマシンからクラスタ・マウントされたデータベース内の $INCREMENT のパフォーマンスは、劇的に改善されています。 これは、ECP クラスタ構成用です。

メモ ： 以下で説明しているように、この状況の危険性は高いですが、これは互換性の問題ではなく、パフォーマンスの問題です。

クラスタの $INCREMENT はすでに数千のユーザをサポートできるほど十分に高速なので、カスタマが影響を受ける可能性は低いでしょう。

csp:search CSP タグによって生成されたコードには、Basic で記述されたページに対する ..QuoteJS(...) メソッド呼び出しが含まれていました。 これは、構文エラーです。 Basic ページに対して生成されたコードは現在、me.QuoteJS(...) を生成します。

以前、BASIC を使用して開発された CSP アプリケーションは、コンパイル中に失敗していました。

以下のように csp:search タグに対して昇順 (ASC)、もしくは降順 (DESC) のサポートを追加します。

ORDER 属性の形式は現在、コンマ区切りのフィールドを使用した形式となっています。

   propname | direction

propname はプロパティ名で、direction は ASC、もしくは DESC のいずれかです。 direction が指定されていない場合は、SELECT 属性、または WHERE 属性のデフォルトが使用されます。

WHERE 属性と SELECT 属性の形式は現在、コンマ区切りのフィールドを使用した形式となっています。

   propname alias | direction

propname はプロパティ名、alias は使用されるオプションの SQL エイリアス、direction は ORDER 属性のこのプロパティに対して使用されるデフォルトの方向 (ASC もしくは DESC) です。

パフォーマンスの向上

SELECT と WHERE リストのエイリアスの使用に関連する以下の修正は、以下の目的で行われています。

1. コンマ区切りのそれぞれのプロパティに対して、エイリアスとしてプロパティ名の後の最初の空白に続くすべてを処理します。 プロパティ名とエイリアスの間にある、オプションの "AS" 区切り文字は虫します。 "name alias" は "name As alias" と同じです。
   
2. 生成された SQL 文で使用されないエイリアスは、今後も必要とされません。 この変更は、エイリアスの区切り文字付き識別子の使用に関するすべての問題を解決します。 フィールド名の区切り文字付き識別子は、正常に機能しているからです。
   
3. order プロパティを渡す変更は、エイリアスではなく、プロパティ名を使用します。 この変更は、並べ替え列のハイライトに関する問題を修正し、SQL 文のエイリアスの使用のみを削除します。
   

CSP Search ページは現在、適切に列エイリアスを使用します。

CSP ファイルをインポートするとき、アプリケーションが他のネームスペースのものであるために適合せず、現在のネームスペースに対して定義された '/csp/namespace' アプリケーションがある場合、CSP ファイルはそこにインポートされます。

これは現在、'/csp/namespace' がない場合でも拡張されておらず、このネームスペースに対してマップを行う、アルファベット順に最初に照合するアプリケーションを取得します。

異なるネームスペースへの CSP ファイルのインポートが改善されています。

Preserve=1 プロセスが突然終了した場合、所有されているライセンスにはライセンス番号のレコードがないので、リリースされることはありませんでした。

この問題は、修正されました。

ライセンスの能力の段階的削減

長い URL を持つページは、ページからクラスへの変換のキャッシュでこのページを表示させようとしたときに、GetCSPClassName+3^%cspServer で CSP エンジンで <SUBSCRIPT> エラーが発生していました。 これは、このグローバル・キャッシュ検索を使用するには添え字が長すぎるとき、検出する際の不完全なロジックが原因でした。

CSP アプリケーションでのエラーの発生

Java プラグイン 1.4.0_03 の Netscape 7.0.2 は、(LiveConnect を使用して呼び出される) Java メソッドの返り値を文字列ではなく、オブジェクトとして処理します。 #server に対する JavaScript は、オブジェクトが Java メソッドから返される場合に "" を返り値 (文字列に変換する) と連結させるために修正されています。

NetScape v7.0.2 での CSP #server の起動は現在、向上しています。

5.0 もしくはそれ以降の構成マネージャでのバグは、4.1 構成ファイルを編集するときに Yes/No 文字列をローカライズすることで修正されています。 このような不要のローカライズは、Yes/No 属性の認識を妨げます。

構成マネージャのユーザ・インタフェースの非英語環境では、不適切な文字が表示されます。 これは、製品自体に問題はありません。

この修正により、従来は切り捨てされていた長いネームスペース名が適切に表示されます。

外観の向上

ドキュメント化されていないグローバル ^%SYS("DOCBOOK","SOURCE") は以前、ドキュメント・ソースが検索されるデフォルトの位置を保持していました。 これは、このようなディレクトリのリストを含むために汎用化されています。 ドキュメントのロードでこのリストを使用することも、現在は説明されています。

DOCBOOK ネームスペース内の独自のコンテンツをロードしている場合は、ソース・ディレクトリを説明しているグローバル構造を再調整するまで、ロードの失敗が続きます。

これは、DocBook.Utils の XMLExport メソッドの使用を試みるときに発生する、2 つのエラーを修正します。

最初に、1 つの DocBook クラスのプロパティに対する不適切な参照が修正されました。 これに先立ち、XML としての参照マテリアルのエクスポートの試みが、<PROPERTY DOES NOT EXIST> エラーを引き起こしていました。

次に、DocBook に対する SoftQuad によって提供された XML スタイルシートに対する参照を生成するために使用される XMLExport の修正が行われました。 これは、アプリケーションがこの機能を使用しなくなった後も存在していた跡で、 これは、5.0 では削除されました。

XML ファイルとしてドキュメントのエクスポートを試みると、従来は失敗していたものでも、現在は正常に機能しています。

大量のクラスのインポートやコンパイルに関する問題は、修正されています。 従来は、この問題はエラーの原因となっていました。

   Run-time error '91':  Object variable or With block variable is not set

XML をインポート中の開発者は、エラーを受け取ることもありました。

この変更により、インストール中に特定のコンポーネントの選択をリセットする環境を修正します。 これは Pentium 4 の特定のコンポーネントと、CSP や WebLink Web サーバの特定のモジュールに影響を与えます。 この変更以前、インストール・プログラムは Web サーバの特定のモジュールをインストールするか否かというユーザの選択を無視していました。 この変更により、ユーザはこれらのモジュールの選択や解除ができますが、ユーザの選択に関係なく、検出されたすべての Web サーバのモジュールをインストールします。 また、Web サーバが検出されなかったときは、ユーザから選択されていてもこれらのコンポーネントのインストールは行われません。

この変更により、対応する Web サーバが検出されない場合、ユーザは Web サーバのモジュールのコンポーネントを選択することはできません。 ユーザは、特定の CSP/weblink モジュールの選択解除することはできます。これは、2 つ、またはそれ以上の Web サーバがインストールされていて、そのすべてに対してユーザが CSP/Weblink をインストールしたくない場合に便利です。

インストールは現在、ユーザの希望をより柔軟に受け入れることができるようになっています。

インターシステムズ・ジャパンの Web サイトからダウンロードされたキットのデフォルトの構成名は CACHEWEB ですが、作成されたショートカットは CacheWeb を参照していました。 Windows のスタート・メニューは大文字と小文字を区別するので、Caché のコントロール・パネルとエクスプローラは起動できませんでした。

今回のリリースでは、修正されています。

低 ： Caché キューブは、この場合でも正常に動作します。

Windows 2000 で Cache 5.0.1 のクライアントのみのインストールを行うとき、サーバ側のコンポーネントもインストールされていました。これは、今回のバージョンで修正されました。

クライアント PC でのディスク使用やアクセスが増大し、認証されていない Caché サーバが導入される可能性があります。

インストールは現在、cboot と同じディレクトリ (Windows の場合は NT\Install) のインストール・メディアで、"cbootuser.rsa" の存在を確認します。 このファイルが存在する場合、インストールはそれをロードし、ルーチン "cbootuser" を実行します。 これにより、カスタマはデータベースの作成、グローバルまたはルーチンのロードなど、Caché がこのメディアからインストールされるたびに、コードを実行することができます。

このルーチンが実行されるとき、ネームスペースは定義されず、オブジェクト・コードも使用されないことに注意してください。 $zutil(5) は、暗黙のネームスペース間の切り替えに使用されます。

なし

ECP 上の逆方向の $order は、<DATABASE> エラーを返していました。

アプリケーション・ユーザは、偽の <DATABASE> エラーを受け取ることもあります。

以前のバージョンでは、OpenVMS と UNIX システムのデフォルト・パケット・サイズは、性能を向上するよう 3600 に設定されました。ネットワークの中には、断片化を実行しないあるいはパケットの再組み立てをしないものもあるため、これにより DCP クライアントがタイムアウトになり、<Server... is down...> メッセージを表示します。 断片化の問題は、オペレーティング・システムやルータ設定が原因となる場合があります。

この問題を修正するよう、すべてのプラットフォームのデフォルト maxudppktsiz パラメータは現在 1468 になります。これは、Caché から送信される最大のパケット・サイズです。パケットを断片化する必要性を除去します。Caché 構成マネージャを使用すると、maxudppktsiz のサイズを最大の 3600 まで増やすことができます。適切に断片化する方法によりネットワークでの性能が若干向上します。

アプリケーション・ユーザに対して、厄介な、しかし適切なメッセージ が表示されます。

この変更により、DB 状態の変更内容 (ディスマウントなど) の間の競合状態と、クライアントのキャッシュ・クリーンアップを妨げることができます。

ECP が失敗することもあります。

特定のまれな状況で、ECP は範囲外の配列を参照していました。 すべてのプラットフォームで、この配列はプラットフォーム・コンパイラによって添付され、さまざまなものがメモリに配置されるまで、問題は公開されませんでした。

さまざまなものがメモリに配置されたら、現在では問題が発生することはありません。

ECP が失敗することもあります。

ネットワークの初期化に時間がかかりすぎるとき、構成された多くのバッファを持つシステムで、ライト・デーモンの起動が失敗していました。この問題は、修正されました。

Caché の起動が失敗することもあります。

この変更により、EXTERNALSQLNAME のつづりが修正されています。 このプロパティ・パラメータは、外部 SQL DB に投影された列の名前を定義するために使用されます。

ODBC クエリが失敗することがあります。

永続クラスがタイプ・クラスがシリアル・クラス (埋め込みオブジェクト) であるプロパティを含むとき、プロパティのタイプ・クラスのプロパティは、列として SQL に投影されます。 投影された列の名前は、<container column>_<serial column> です。

5.0.1 以前のバージョンでは、このプロジェクションは埋め込みの 1 つのレベルのみに制約されています。 5.0.1 では、埋め込みの複数のレベルで SQL に投影することができます。 投影された列名は以前と同じ形式を使用しますが、<container column> もシリアル・クラスから投影された列になりえます。

例えば Class City は、プロパティ City、State、Country、および PostalCode を持つシリアル、 Class Address は、プロパティ Street (タイプ %String) と City (タイプ City) を持つシリアルで、 Class Person は、プロパティ Home を Address として持っています。

この変更前は、Home_Street と Home_City のみが列として SQL に投影されていました。 現在は、Home_Street、Home_City (非表示)、Home_City_City、Home_City_State、Home_City_Country、および Home_City_PostalCode が投影されます。

複数レベルの埋め込みオブジェクト・プロパティのプロジェクションの拡張

従来の CDL ファイルは、Caché の以前のバージョンでのエラーにより、メソッドの形式仕様の周囲の余分な '()' を持つこともあります。 このような CDL は、形式仕様の余分な '()' が原因でコンパイルできませんでした。 現在は、CDL がこの問題を避けるためにロードされるときに、余分な '()' は除外されます。

開発者が特定の CDL ファイルをロードすることを妨げます。

この変更により、クラス・コンパイラが SQL ソースを INT コードで標準 MAC コンパイラとして保持したい場合、クラス・コンパイラは同じフラグを使用することができるようになります。

Query メソッドを使用するオブジェクト・アプリケーションのデバッグが、より困難になりました。

以下のプロパティを持つクラスを生成する場合、

   Property Array As %String [ Collection = array ];

   Property Index As %Integer;

以下のようにメソッドを生成します。

Method Test()
 {
   Write ..Array.GetAt(..Index)
 }

これを完全な最適化の状態でコンパイルする場合、この Test メソッドから生成されたコードは誤ったコードとなります。 生成されたコードは現在のオブジェクトではなく、'..Array' オブジェクト内で '..Index' の検索を試みます。 現在、Caché は最適化を適切に挿入します。

クラス・コンパイラ・オプティマイザは現在、コレクション用の適切なコードを生成します。

式メソッドが '(a=1)||(a=2)' のような場合、クラス・コンパイラは括弧を追加せずにそれを置換します。したがって、コードが以下の場合、

   Write '..Expr(var)

以下のように終了します。

   Write '(var=1)||(var=2)

この式が括弧で開始し、括弧で終了するとしても、これは検出していませんでした。 追加の括弧が必要とされ、現在では式は置換されます。

   Write '((var=1)||(var=2))

アプリケーション・エラー

'##super' を使用するとき、これが最初に行うことは、このメソッドが最初に実装された場所を検索し、そしてこのクラスのスーパークラスを検索することです。 しかし、このメソッドがジェネレータ・メソッドの場合、クラスはすべてのレベルで '実装され' 、したがって現在のクラスのスーパークラスを検索します。

##super 指示語は現在、メソッド・ジェネレータ・メソッドと機能します。

JBoss ディプロイメント・ディレクトリから jar を検出しました。 これにより、CMP ディプロイメントが BMP ディプロイメントに従うことができるようになります。

現在、BMP ディプロイメントの使用後に CMP EJB ディプロイメントを使用することができます。

CMP 生成が Caché シリアル・クラスのサポートを生成するとき、そのシリアル・クラスが "永続" (参照) を持っている場合、その参照の JNDI 名は不適切に生成されてしまいます。 その前に接頭語 BEANNAME に対して JNDI の生成を変更します。

EJB CMP 生成は、シリアル・クラスに対して改善されています。

メソッド CacheDatabase.getDatabase(java.sql.Connection) を使用して Java バインディング接続のオープンやクローズを行うと、メモリ・リークが発生していました。 今回のリリースでは、修正されています。

Java ベースのアプリケーションでは、不十分なメモリのためにクラッシュしてしまうことがあります。

現在は、入れ子にされたシリアルのサポートを行います。

S2 (serial - シリアル) を含む S1 (serial - シリアル) を含む P (persistent - 永続) を持っていると想定します。 そして、それらがすべて Pack1 と言うパッケージ内にあるとします。 S1 から S2 にアクセスすると思うかも知れませんが、実際は P から S2 にアクセスします。 例えば、依存オブジェクト Pack1.EJBS2 を持っているとします。 Pack1.EJBP のプロキシであるリモート EJB オブジェクト p に対するこの依存オブジェクトの値は、以下のように取得され、変更されます。

上記の s2 は Pack1.EJBP を初期化する依存オブジェクトです。

以下のような形式も使用できます。

EJB プロジェクションは現在、入れ子にされたシリアル・オブジェクトと動作します。

入れ子にされたシリアルは、それが "非表示" としてマークされていたとしても、シリアル・コンストラクタにロードされる必要があります。 またフィールドの投影のロジックも、シリアル・セット・アクセサのフィールドを適切に設定しません。

ユーザは、非表示から表示にフィールドを変更したり、その逆を行う場合には、EBJ コードを再生成し、リコンパイルする必要があるということに注意しなければなりません。 通常、クラスの属性を変更する場合は、EJB サポートを再生成する必要があります。 フィールドを非表示から表示へ、またその逆を行う変更はユーザの EJB コードの動作に影響を与えないように思われますが、Caché では、クラス属性を変更する場合は完全に再生成が行われる必要があります。

アプリケーション・エラー

メソッド readResponse() の %Net.FTPSession では、エラーが発生した場合、現在のデバイスはリセットされませんでした。 これは、TCP/IP デバイスとして FTP サーバに任されていました。

アプリケーション・エラー

現在のデバイスに表示されることを防ぐために、'-d' フラグを使用した %Routine クラスでの Compile メソッドの呼び出しは動作していませんでした。 ルーチンでエラーが発生した場合は、表示が行われていました。 この変更により現在は、'-d' フラグは有効です。

なし

この変更により、以下の 2 つのクラス・メソッドが %File に追加されます。

• GetDirectoryLength(dirname) は、このディレクトリ名の複数の部分、例えば Windows 環境での 3 つの部分である 'c:\temp\mysub' などを返します。
  
• GetDirectoryPiece(dirname,piece,.fullpath,.isdirectory) は、ディレクトリ名からユーザが必要とする部分を返します。
  

例えば、'c:\temp\mysub' を使用した場合は以下を返します。

 Piece Return FullPath       IsDirectory
 1     c:     c:             1
 2     temp   c:\temp\       0
 3     mysub  c:\temp\mysub  0

なし

Webmethod をクラス・メソッドのキーワードとして使用する制約のみが導入されていますが、Reader はいまだにこの変更を反映するように更新されていません。 Reader は現在、インスタンス・メソッドを適切に生成する代わりに、クラス・メソッドを生成します。

なし

キーワード WebMethod は現在、%SOAP.WebService のサブクラスで指定されたクエリでサポートされています。

SOAP 経由で呼び出し可能な Web メソッドは、そのクエリと関連する入力されたデータセットを返すクエリとして、同じ入力引数を持つように作成されます。

また、Web サービスが pkg.class で、クエリの名前が QueryName の場合、クラス pkg.class.QueryName は入力され、クエリを表示する %XML.DataSet のサブクラスとして作成されます。

クエリに対する WebMethod 使用の例は、SOAP.Demo Web サービス・サンプルに添付されています。

なし

SoapBindingStyle プロパティ・キーワードと SoapBodyUse プロパティ・キーワードは現在、サポートされています。 これらのプロパティ・キーワードは、WebMethod キーワードを持つメソッドのキーワードと同じようなものです。

SoapNameSpace プロパティ・パラメータは、Web クライアントに対してのみ使用されます。

なし

この変更により、SoapBodyUse、SoapBindingStyle、および SoapNameSpace メソッド・キーワード、またはクエリ・キーワードに対するエラー・メッセージが、メソッド名、またはクエリ名をメッセージに追加することで改善されました。

外観の変更

現在、LOCATION が http://、または https:// で開始しない場合はエラーが発生します。 http を使用すると、外部トンネルが必要であることに注意してください。

デバッグを行うと、追加された情報でより簡単になります。

%XML.Adaptor のサブクラスのコンパイルを試みると、定義された変数は残されたままになっていました。 それらの変数が適切にクリーンアップされるように、適切な New コマンドがメソッド・ジェネレータ・コードに追加されました。

XML のエクスポート後は、余分な変数は存在しません。

従来は、非常にまれな状況で内部 "仮想" クラスをコンパイルすると、子テーブルが SQL に投影されていました。この問題は、修正されました。

なし

ビットマップ・インデックスがテーブルに追加されるとき、以降のクエリの結果は不適切なものです。 ビットマップ・エクステント・インデックスは、最初のビットマップ・インデックスがテーブルに追加されるときに自動的に構築されません。

ビットマップ・インデックスが構築され、ビットマップ・エクステント・インデックスにデータが存在しないときは常に、そのクラスに対するビットマップ・エクステント・インデックスは、各サブクラスに対するビットマップ・エクステント・インデックスとともに自動的に構築されるように、%BuildIndices は更新されています。

SQL クエリが、不適切な結果を返すこともあります。

これは、プロパティ自身がグローバル・ノード ('node' 構造) に格納されるときに発生する問題を修正します。 この問題は一般的に、コレクションがサブノード構造に格納され、結果の構造が子テーブルとして SQL に投影されるときに発生します。 報告されるエラーは、以下の通りです。

   ERROR #5502: Error compiling SQL Table ...

アプリケーションはコンパイルできません。

OpenVMS で Caché スタジオを使用して XML ファイルをリモートでエクスポートし、そのファイルを再インポートすると、ルーチンがすべて 1 行に格納され、コンパイルが失敗していました。 この問題は修正されました。

開発の妨げとなります。

サイズが 32767 文字、またはそれに近い値を持った $system.OBJ.Export エントリ・ポイントを使用してグローバルをエクスポートし、次にそれをインポートした場合、以下のようなエラー・メッセージが表示されることがありました。

   characters^%occSAX in c:\test.xml at line 581 offset 1

これは、グローバル・ノードがインポートされた後に適切に変数が消去されていなかったためです。今回のリリースでは、修正されています。

開発の妨げとなります。

式メソッドをエクスポートするとき、コードの最初の行の前にメソッドのボディー・コードに対する CDATA の開始後に、Cr/Lf を挿入するのではなく、単独の行でXML へのエクスポートをフォーマットします。 これにより Caché 5.0.1 でエクスポートされたクラスは、Caché 5.0.0 で適切にインポートできるようになります。

v5.0.1 からエクスポートされたクラス定義は、v5.0 でロード可能になります。

%XML.DataSet が Web サービスから返されるとき、これは Microsoft の .Net データセットとして投影します。 従来は、タイプ付けされていないデータセットのみがサポートされていました。 この変更により、Web サービスに対する WSDL でのタイプ情報を含む、タイプ付けされた .Net データセットへのサポートが追加されます。 この追加の情報によって、Visual Studio .Net は IntelliSense をサポートするタイプ付けされたデータセットを生成することができるようになります。

NAMESPACE パラメータが指定され、CLASS と QUERY パラメータがデータセットの基となるクエリを指定するためにオーバーライドされる場合、%XML.DataSet のサブクラスはタイプ付けされたデータセットを生成します。

タイプ付けされたデータセットの返り値の例は、SOAP.Demo サンプルに追加されています。

Visual Studio .Net は IntelliSense をサポートするタイプ付けされたデータセットを生成することができるようになります。

XML 使用可能なクラスのプロパティによって参照されるクラスは、XML 使用可能である必要があります。 従来は、参照されたクラスが XML 使用可能でない場合、<METHOD NOT FOUND> エラーが発生していました。 これは、問題をより明瞭に表現するエラー・メッセージに改善されています。

なし

Caché の単純な型を XML スキーマ型 "literal" にマッピングするとき、Caché の VALUELIST データタイプ・パラメータを表す一覧表の内容を使用します。 XMLImport はすでに、VALUELIST に基づく型のチェックをサポートしています。 この変更により、XMLSchema が VALUELIST を表す一覧表の内容を出力することができるようになります。

一覧表は "encoded" 形式のスキーマではサポートされません。Microsoft Web サービスが BodyUse="encoded" の一覧表をサポートしないからです。

クラスは現在、より多くの情報を含む XML スキーマを生成します。

XMLExport 出力の任意のインデントを、XMLExport 呼び出しの形式引数によって決定されたようにサポートします。 デフォルト・インデントの振る舞いは、空白のない 1 行として XML を出力する現在の振る舞いです。

"インデント" を形式引数に追加すると、XMLExport 出力がインデントされます。 "indent" は、形式の literal/encoded の部分からコンマで区切られています。 使用されるインデント文字は、形式引数で "indent" の後に続く括弧で使用されるインデント文字列を囲むことで指定されます。 指定されない場合は、デフォルト・インデント文字列は 2 つの空白です。

例 ： oref で参照されるオブジェクトを、デフォルトの 2 つの空白インデントで出力する方法は、以下の通りです。

   set sc=oref.XMLExport(,",indent")

oref で参照されるオブジェクトを、3 つの空白インデントで出力する方法は、以下の通りです。

   set sc=oref.XMLExport(,",indent($c(32))")

空白 ($c(32)) を引数として渡すと、インデントのサイズを インクリメント することに注意してください。これは、インデントのサイズを指定しません。

oref で参照されるオブジェクトを、タブ・インデントで出力する方法は、以下の通りです。

   set sc=oref.XMLExport(,",indent("_$c(9)_")")

生成された XML の外観の向上

Rewind メソッドを %XML.Reader が呼び出されるときに追加すると、相互関係を消去し、XML ドキュメントの最初から読み込みを再開します。 相互関係は、Rewind 後に再度呼び出される必要があります。

%XML.Reader は使用がより簡単です。

XML ファイルをロードするとき、ユーザが指定したデバイスを保持するのではなく、現在のデバイスは $PRINCIPAL デバイスに変更されます。 これは現在、適切なデバイスを記憶しています。

クラスのインポートは、主デバイスを適切にリストアします。

Class Query 定義は現在、DO メソッドと同じ SOAP 関連のキーワードを持っています。 これにより、クラス・クエリの SOAP バインディングを制御できるようになります。

クラス・クエリは、より多くの SOAP オプションをサポートします。

マップされたテーブルを示す外部キーを削除すると、以下のエラー・メッセージが返されていました。

これは、修正されました。

DROP FKEY を行うと、現在では SQL テーブルは従来の構造に適切にマップされます。

以下のシーケンスは、

   create table P(a integer primary key, b varchar(20))
   create table F(one integer primary key, two integer)

   insert into F(one,two) values (1,1)
   alter table F add constraint toP foreign key(two) references P(a)

Cache 4.1.6 まではは正常に機能しますが、Cache 5.0.1、Cache 4.1.9 でもエラーを返します。 これは現在、エラー -127 <FOREIGN KEY Constraint failed referential check upon creation of the constraint> を返します。

制約チェックは実行されません。

この変更により、^%SYSLOG グローバル内の SQLGateway に対するすべての呼び出しを記録することが可能になります。 外部テーブルの初期では、行うことができました。 現在は、SQLGatewayConnection クラスでも同様の機能が使用できます。

デバッグがより簡単になりました。

JDBC パーサーは、"*=" をエラーとして不適切に報告していましたが、これは、修正されました。

JDBC ドライバは、従来の JOIN 構文を適切に認識します。

この変更により、ResultSets からのデータ値の戻りに関連する、複数の欠陥が修正されています。以下は その概要です。

特定の状況で、JDBC はデータを適切に返しません。

JDBC リパーサーは、'_' で開始する名前を認識しませんでしたが、これは、修正されました。

開発の妨げとなります。

この変更により、CacheODBC を OpenVMS にポートし、インターシステムズの ODBC ドライバを使用した転送に対して、動作する IODBC.exe ドライバ・マネージャを提供します。

OpenVMS クライアントから ODBC アクセスがありません。

OpenVMS プラットフォームに対して SQLGateway をポートし、 3.0 ODBC API を含むために IODBC を再度ビルドします。

OpenVMS クライアントから ODBC アクセスがありません。

Microsoft Access は、値を比較するときに一貫性のある方法で数値主キーを処理しません。 Access は通常、最初の主キー 10 個で内部比較を行います。内部式と一致しない場合、与えられた行に対して #Deleted 値を返します。

インターシステムズの ODBC ドライバは、スケールが 2 の場合に 0.00 として SQL_C_CHAR や SQL_C_WCHAR に変換された数値データを一貫してフォーマットします。したがって、SQLServer は .00 と同じデータを返します。 .00 を返すことで Access の #deleted の問題を修正しますが、これは値 0 に対してのみ行われます。 SQLServer は Access で負の数を処理しないので、小数点の前の先頭の 0 を返す変換は Access では機能します。

Access が 0.00 を 0 や .00 とは異なる扱いをする理由は、Access のみに見られるバグと思われます。 ドライバは "0.00" ではなく ".00" を返すことで対処できるようになります。 これは 0 の値のみに対するわずかな形式の変更ですが、Access で数値主キーを使用することがよりよい方法と思われます。

不完全なクエリの結果

ログで報告されたドライバ名、または SQLGetInfo に対するドライバ名は Windows では適切ですが、OpenVMS や UNIX プラットフォームでの実行可能な適切な名前を反映しませんでした。

開発の妨げとなります。

無効なネームスペースを含む ODBC DSN (Windows 上) に接続を試みる場合を処理するために、"Invalid Namespace" メッセージを追加しました。

なし

ADO が Caché にストリームを挿入するために使用されるとき、メモリ・リークがありましたが、今回の変更で修正されています。

Windows クライアント上で利用できるメモリが徐々に失われていました。

文字ストリーム・フィールドはデフォルトのディスプレイ・サイズ "2147483647" を返します。このサイズでは、以下の printf フォーマット・コマンドがコア・ダンプし、失敗します。

   printf("%-*s", (int)display_size, pcolname);

これは、display_size により小さい値でこれらをフォーマットするために printf に損害を与えないので、Caché はエラーが発生しないように MAX_DATA (1000) をコード内で使用します。

これはサンプル・コードなので、ユーザはデフォルトのディスプレイ・サイズが大きい文字とバイナリ・ストリームとの作業を行うときは注意する必要があります。また、大量のデータのこの型を読み込むために、アプリケーションをカスタマイズする必要もあります。

アプリケーション・エラー

パスワードなしでユーザを SQL で作成したとき、そのユーザが ODBC ドライバ経由でログインする方法はありませんでした。

開発の妨げとなります。

こ変更により、最大長 32000 を持つ "string" フィールドの問題を修正しました。

新規の行を挿入すると、Caché グローバルに格納されたときに、各文字の後のフィールドに NULL 文字が挿入されます。 例えば、"ABC" は以下のようになります。

    A_$C(0)_B_$C(0)_C_$C(0)

アプリケーション・エラー

現在は、サブクエリの結果を保存することで、関連するサブクエリを最適化しています。 同じ関連するフィールド値が再度表れた場合、サブクエリの結果は再度実行することなく検索可能です。

クエリは、過剰な CPU 時間を使用することもあります。

1 つの引数がフィールドで、もう 1 つが定数、またはホスト変数であるときに関連して、'=' などのバイナリ演算子で使用される同じロジックで IN を適用していました。 これは通常、タイプ %Date/%Time のフィールドにのみ適用されますが、部分文字列の検索を試みるときに、文字列演算子は不適切な結果を返すこともあります。

部分文字列の処理は現在、より正確になっています。

特定の状況で、複数のインデックスが OR 条件を満たすために使用された場合、誤った答えが返されていました。

また Caché は現在、複数のインデックスが使用されるときに、インデックスに対する IS NULL 条件のアプリケーションを最適化します。

複雑な条件を含む WHERE 節は、インデックスの存在によって異なる結果を返すこともあります。

SERIAL_FIELD 列は、%Library.SQLCatalog.SQLFields(...) カタログ・クエリに追加されています。 この列には、フィールドがシリアル型である場合は "Yes"、それ以外の場合は "No" が含ます。 詳細は、クラス・ドキュメントを参照してください。

%Library.SQLCatalog の SQLFields クエリは現在、追加の列を持っています。

これは、Join が未定義のエラーで実行時に失敗する問題を修正しています。

特定の状況で、照合済みのフィールドの前に検索された未照合のフィールドに対して生成された、不適切なコードがありました。これは、実行時に <UNDEFINED> エラーを返していました。

これは、フィールドが照合を持ち、外部結合がインデックスによって満たされないとき、<const>=*<field> の場合に発生します。

クエリのコンパイルが失敗することもあります。

これは、New が実行された複数の変数が、すでに使用されなくなった後でも削除されない問題を修正します。

アプリケーション・エラー

これは親参照フィールドが、子テーブルの IDKEY インデックスの最初以外の位置で指定されているときに発生するエラーを修正します。

アプリケーション・エラー

クエリへ count(*) 列を追加すると、返された ResultSet が "ORDER BY" 節を無視する結果になる問題を修正しました。

クエリの実行が遅くなることがあります。

2 つのバグは %CacheSQLStorage で修正されています。

• {<n>D} (例えば {2D}) 参照は、Over-ride NEXT 添え字コードで使用されるとき、アクセス・レベルとして適切に認識されていませんでした。これは、今回のバージョンで修正されました。
• {table.field}_{table.field2} などの添え字式は、フィールトが存在しないというエラーを返していましたが、これは、今回のバージョンで修正されました。

アプリケーション・エラー

{fn IFNULL(<column>,val)} の結果は常に、データタイプ SQL_VARCHAR でした。 現在、Caché は <column> のデータタイプを適切に返します。

開発の妨げとなります。

Informix からテーブル定義をインポートするとき、すべての列は NOT NULL (これらの列のデータは必要ない) としてマークされていました。

開発の妨げとなります。

SQL マネージャは、ビューの所有者を変更できるように修正されています。

なし

リンク・テーブル・ウィザードで、ユーザが新規のテーブル名を入力し、そのテーブル名に空白や他の文字が含まれる場合、ウィザードは "Invalid table name" エラー・メッセージを返していました。 今回のリリースでは、修正されています。

開発の妨げとなります。

SQL マネージャは現在、日本語の文字を適切に印刷することができます。

SQL マネージャの操作の妨げとなります。

これは、Caché スタジオで XML パーサーが "<!" シーケンスを検索しながらループする問題を修正します。

開発の妨げとなります。

これは、Caché スタジオで、スタジオが Color テーブルの記憶を失敗する問題を修正します。 しかし、スタジオ A がテーブルを編集し、スタジオ B がすでに起動している場合、スタジオ B は編集前のテーブルの使用を継続します。そのテーブルがレジストリに保存され、変更の通知が相互に行われていないためです。

開発の妨げとなります。

これは Caché スタジオのさまざまなダイアログで、ダイアログ・ボックスやボタンの焦点が合わなくなる問題を修正しています。

開発の妨げとなります。

この変更により、クラス・コンパイルによって生成された INT ルーチンの検出が向上しました。 この変更は、INT がクラスから生成されていないときにクラスから生成されたとコンパイラが決定するような状況、またクラスが無効であるというエラー・メッセージの原因となる、クラス記述子を再生成しようとする状況を防ぎます。

開発の妨げとなります。

OpenVMS では、ディレクトリは 'ABC.DIR;1' ファイルとして表示され、%File クラスでは適切に表示されませんでした。 また、ディレクトリは ##class(%File).DirectoryExists(dir) メソッドでそれ自体をディレクトリとして報告していませんでした。 ファイル名の解析も、名前の部分間に '.' を追加しませんでした。これは、今回のバージョンで修正されました。

開発の妨げとなります。

クラスをオープンするとき、Caché スタジオはサーバに対して無関係の大量の要求を作成していました。 例えば、%ResultSet をオープンすると、7 つの要求のみが必要とされるのに 277 の要求が作成されていました。 %ResultSet が 7 つの必要な要求のみが作成される場合には、これらの不必要な要求は回避されます。

開発の妨げとなります。

%RoutineMgr クラスの genPattern クラス・メソッドを呼び出すと、メソッドが完了した後、変数 'tN' が残されます。New が実行されなかったためです。

アプリケーション・エラー

修正された問題は、以下の 2 つです。

• Ctrl/keypad+ と Ctrl/keypad- は、ExpandAll と ContractAll を受け入れませんでした。
• Ctrl/+ は、+ がシフト文字ではないドイツのキーボードで動作しませんでした。

開発の妨げとなります。

複数の XML テキストの入れ子レベルが 8 レベル以上になったとき、質問の行はウィンドウの右端に移動され、入れ子制限のチェックのバグにより、その行を編集することができませんでした。

これは今回のバージョンで修正され、最大入れ子レベルは 32 まで拡張されました。

開発の妨げとなります。

クラスタで、1 つのクラスタ・メンバーがクラスをリコンパイルする場合、そのクラスが (新規の) クラス記述子をリロードできるようにロードされている場合、他のクラスタ・メンバーはそのクラスを無効にする必要があります。

アプリケーション・エラー

従来は、特定の一般的でない状況で Caché クラスタでシステム停止の原因となる問題がありました。 これはフリー・バッファが 0 であるために、ライト・デーモンがパニック・モードになっているときに発生していました。 これは、今回のバージョンで解決されました。

製品アプリケーションの停止

ジャーナリング・デーモンは、ユーザがジャーナル・キューに追加を行ったときに、不必要な休止、または起動を回避するために変更されました。

なし

ハイパースレッドがアクティブのとき、Windows は物理的 CPU 数の代わりに、スレッド数を報告します。 これは、エンタープライズ・ライセンスを使用していないシステムで許可されている、認証された CPU 数で不適切な制限を行う原因となっていました。 この変更により、物理的 CPU 数がライセンスの機能範囲をチェックするように修正されています。

ライセンスの機能範囲が減少していました。

$System.License クラスは、ライセンスの使用に関する情報を提供するように、追加のメソッドで拡張されています。

なし

メモリ不足で起動が失敗した後、それ以降に (すべての config ファイル付きで) Caché の起動を試みた場合には以下のメッセージが表示され、

   "A global section with the name "_CACHE__[etc]" already exists"

Caché は停止します。 この状態は、config ファイルの使用に関わらず、システムがリブートされるまで改善されません。

製品の再起動を妨げます。

フル・メモリの配置に失敗した場合、OpenVMS での Caché はアクセス違反となります。これは、今回のバージョンで修正されました。

製品の起動を妨げます。

これは、添え字なしのグローバルや配列に対する参照が、添え字として NULL 文字列を使用した参照と同じ結果となるように $QUERY を修正しました。

アプリケーション・エラー

これは、2 つの異なるネームスペースで識別できるように名前を付けられたルーチンで、お互いの呼び出しが適切なルーチン参照の再構築に失敗するエラーを修正しています。 これは、<EDITED> エラーとなっていました。

アプリケーション・エラー

複数の負の浮動小数が、$LISTBUILD 関数で定数値として使用されていたとき、Caché ObjectScript コンパイラは無効なオブジェクト・コードを生成していました。 この無効なコードは、そのコード行が実行されるときに処理が停止する原因となっていました。 問題の原因である定数は、-.1、-.01、-.001 などです。 定数の使用のみが、この問題を引き起こします。 数が算術演算によって生成されたか、または以前に変数に格納されていた場合、オブジェクト・コードは適切です。

アプリケーションの中止

データベース数が 255 を超えたときに発生する可能性があるさまざまな問題を修正してきました。

データベースのオペレーションが失敗することもあります。 失敗の実際の原因は、解明できません。

これは、4 GB 以上のバッファ・プールで、プールのオフセットを 32 ビット・セルで格納することで切り捨てるときに発生する問題を修正します。

アプリケーションの失敗

リソース統計カウンタは、64 ビットの PowerPC システムで適切に動作するために修正されました。 特定の内部統計は、AIX プラットフォームでゼロにされています。

統計は、PowerPC システムで正確に保持されています。

これは、シャットダウン中のバス・エラーという結果になる、エラー・ロギングの内部の問題を修正しています。

シャットダウン中の製品の失敗

これは、独自の oref を持つ変数が新規の値に割り当てられたときに、オブジェクト・デストラクタの実行中の遅れの原因となる内部エラーを修正します。

アプリケーション・エラー

UNIX システムでは、CACHETEMP は "スパース・データベース" として構成されています。 これは、拡張されたときに Caché は、強制割り当てを必要とするファイルの新規のブロックすべてを記述しないことを意味しています。 この機能は、Caché がファイルの新規のスペースの最後のブロックを記述するように更新されています。 これは、更新されるファイル・サイズを強制します。

これは、プロセスが予期しないファイルの最後のエラーを読み込んだり、移動したファイルの最後がファイル拡張プロセスで組織化されることを検出する処理を行うコードとして、この新規のスペースを記述することを防ぐために重要です。

アプリケーション・エラー

システムがグローバル・バッファ外になり、パニック・モードになるような一般的でないイベントでは、利用可能なバッファのカウントが sync 外になることが可能でした。 よりまれな状況でも、これはシステム停止を導く可能性がありましたが、大半は気付かれないままです。 システムがパニック・モードになるたびに、これに対する注意がコンソール・ログ・ファイルで作成されます。

製品アプリケーションの停止

データベース圧縮コード (Caché コントロール・パネルでのグローバル圧縮オプションと GCOMPACT) は、ライト・デーモンのパニック状態をトリガするために、すべてのフリー・バッファの使用を回避することを試みます。

GCOMPACT は、アプリケーションの応答時間を遅らせます。

OpenVMS システムと、一度に 64 MB 以上拡張するように設定された 8 KB データベースに影響を与える拡張の問題は、解決されています。 これは、データベースが部分的にしか拡張されない結果となる断続的な問題でした。つまり拡張時に 1 つ、または複数の 64 MB 分のスペースが追加されますが、要求されるすべてのスペースではありませんでした。 拡張が失敗したとき、99524 のエラー・コードは SYSLOG テーブルで記録されていました。

なし

OpenVMS システムで Caché の複数のコピーをインストールすると、Caché の各コピーは異なる UIC グループで起動し、両方のインストールがネットワークを構成したり、^PERFMON などのパフォーマンス監視機能の使用を試みたりする問題は解決されています。

従来は、起動する 2 番目のインストールが、最初のインストールが実行中であることを検出できず、ネットワーク共有メモリ・セクションの名前で混乱していました。 修正後は、2 番目のインストールは適切に起動し、シャットダウン時に最初のインストールのネットワーク共有メモリ・セクションを削除するという結果になっています。

製品の停止

UNIX や Windows システムで、ディスマウントされたデータベースが、CACHE.DAT ファイルを削除することでそのデータベースも削除される場合、MSU がデータベースを再作成しようとするエラーを受け取っていた問題は修正されました。

システム・オペレータの妨げとなります。

この変更により、プロセスがブロックやリソースを所有している場合、停止する呼び出しをスキップします。

製品の停止

新規の $System クラス・メソッドは、ホスト・システムから環境変数の値を取得するために実装されています。

   Set value=$System.Util.GetEnviron(VariableName)

この呼び出しは、"VariableName" に関連する値を (定義されている場合は) 返します。 それ以外の場合は、空文字列を返します。 UNIX や Windows システムでは、変数はコマンド・シェル変数です。 OpenVMS では、これは論理ではなく DCL 符号です。

OpenVMS では、$ZU(12,logicalname,4)、または $ZF("TRNLNM",logicalname,...) を使用して論理に対する変換を取得できます。 $System.Util.GetEnviron() を使用して値の 1 つにアクセスしたい場合は、以下のように最も単純な属性 F$TRNLNM(logicalname) に関連する DCL 式でそれを使用することができます。

   SYS$LOGIN = F$TRNLNM("SYS$LOGIN")

なし

他のプロセスが停止を試みている間に、ジョブがグローバル・バッファを保持することで起きた停止は、修正されています。

製品の停止

$system.Util.SetPrio(prio[, pid]) は、呼び出し側のプロセスの優先度、または ID が PID である他のプロセスの優先度を設定します。

Windows や OpenVMS では、呼び出し側は他のプロセスの優先度に対して無制限のアクセスを持っています。 UNIX では、呼び出しプロセスがルート (Caché のターミナル・プロセスのデフォルトではない) として実行していなければ、他のプロセスの優先度は減少のみ設定できます。

なし

これは、OpenVMS プロセスで誤った優先度を示す $zu(60) の、長年に渡る矛盾を修正しています。

わずかにパフォーマンスが落ちるプロセスもあります。

OpenVMS ジョブの優先度は、Windows や UNIX と適合します。

ジョブ化されたプロセスは、親となる現在のベースの優先度に加え、システム定義のジョブ優先度修飾子で実行します。 ジョブの優先度修飾子は、$system.Util.JobPrio() を使用して設定されます。

なし

クラスタ・マスタが使用不可能になったとき、新規のマスタはジャーナルのロールフォワードを実行し、使用不可能になったマスタのジャーナル・ファイルからロールバックを実行します。 しかし使用不可能になったマスタのトランザクション状態や、保留中の ECP メッセージを再構築する必要はありません。

以前の振る舞いは修正されています。

なし

複数の DCP 接続がクライアント・システムで構成されており、各リモート・サーバにトランザクション・オペレーションがあるとき、トランザクション・ファイル・カウント配列の位置が各 DCP 接続で重複するので、問題が発生していました。 特定の状況では、DCP 上の TROLLBACK や TCOMMIT 実行が完了しないこともあります。

データの損失

この変更により、以下の問題が修正されています。

プロセス A で

   LOCK ^x(1,2,3)

成功します。

プロセス B で

   LOCK ^x(1,2,3)

プロセス A を待機して停止します。

プロセス A で

   LOCK +^x(1,2):0 w:$t   // $T is zero

ロックは与えられません。

^x(1,2):0 をロックするプロセス A に対する適切な振る舞いは、ロックを与えることができることで、$T は 1 です。

プロセス A はクライアント・ジョブで、プロセス B がサーバ・ジョブのとき、この変更は ECP/DCP ネットワークにも適用されます。

アプリケーション・エラー

ジョブがリモート・ロックを要求し、タイム・アウト後にそれをキャンセルするとき、発生する可能性のあるシステムの割り込み状態が ECP クライアントのリード・デーモンにあります。 ジョブが他のリモート・ロックを要求するとき、そのジョブはサーバ上でロックを実際には与えずに返されることもあります。 サーバから与えられた応答が到着する前に、ジョブが 2 番目のロックを解除する場合、ECP デーモンは中止します。

今回のリリースでは、修正されています。

製品の失敗

OpenVMS プラットフォームでの 5.0 で、DCP ネットワークの問題が修正されています。 クライアント・ジョブが長い文字列のグローバル (コンパイルされたルーチンの OBJ コードなど) にアクセスを試みるとき、停止する可能性がありました。

この問題は、Caché 5.0 OpenVMS プラットフォームでのみ発生していました。他の 64 ビットのプラットフォームでは、大規模なバッファ・プールが構成されなければ、問題が発生することはありませんでした。このような場合は、DCP ネットワークで失敗するのみでした。 DCP クライアント・ジョブが長い文字列のグローバルを取得すると停止しますが、Control-C は停止を中断できます。

アプリケーション・ユーザは、CTRL-C を入力するまで保留状態となります。

現在、^LOCKTAB は 'available' と 'usable' の 2 つのロック・テーブル・サイズを表示します。 'available' サイズは以前表示されていたサイズです。これは、ロック・メモリの合計から、使用されるロック・エントリのメモリを引いた数です。

'usable' サイズは、各パーティション (ジョブ) のキャッシュ・メモリと、フリー・キューの複数の LHB ブロックを 'available' サイズから引いたものです。 公式は以下の通りです。

   free size = 'available' size
             - total cached size
             - total free LHB pool size.

   'usable' size = free size
             + (2/3 of free size or total free LHB size which ever is smaller).

なし

データベース圧縮は、同じデータベースで同時に複数の繰り返しを実行するために許可されていました。 これは現在、ロックを使用することで回避されています。

データベースのパフォーマンス低下

従来は、照合タイプ 0 のグローパルは、標準タイプ 5 の変換に対して GBLOCKCOPY によって選択されませんでした。 今回のリリースでは、修正されています。

MSM からの転送が遅れます。

GBLOCKCOPY を使用してデータベースから他のデータベース、またはネームスペースにデータをコピーするとき、コピーされたブロック数が、コピーする計算されたブロック数と一致しないというエラーが報告されることがありました。 しかし実際には、データは正常にコピーされていました。これは、今回のバージョンで修正されました。

操作が煩雑になります。