このドキュメントには、以下のセクションが含まれています。

• Caché の最新ニュース、アラート、アドバイザリ
• 全般的な強化
• オンライン・ドキュメント
• 変更レポートの説明
• 今回のリリースで重要な変更点のリスト
• 新機能または強化された機能の概要
• 今回のリリースでドキュメントに追加された変更の概要

インターシステムズは、当社のソフトウェアをお使いのユーザに対し、早急に必要となる重要な情報を随時発表しています。この中には、警告、不可避の問題点、重要な更新、修正、Caché のリリースなどがあります。

最新のリストは、インターシステムズの Web サイト から取得できます。

ユーザはこのリストを定期的にチェックし、お使いのアプリケーションの処理に関連する問題がある場合、その最新情報を確認してください。

インターシステムズは、不可避の問題によって必要となる修正とは別に、Caché の全般的な機能を適宜強化しています。このバージョンには、そのような機能強化が組み込まれています。

インターシステムズは、ユーザの利便性を考慮し、当社 Web サイト で最新バージョンの Caché ドキュメントにオンライン・アクセスできます。

当社ホームページで [Caché] タブをクリックし、[製品情報] メニューの [技術資料とカタログ] を選択してください。あるいはこのリンクをたどってください。

今回の変更による影響をお使いのアプリケーションで認識するため、各変更の解説では、修正点を詳細に説明しています。

すべての変更に対し、問題発生の可能性、変更による影響、実運用しているシステムで製品が問題なく動作しているかなど、関連情報を示した表があります。表では 1 つまたは 2 つのキーワードと値のみ使用し、情報を簡単に認識できるようにしています。キーワードの意味は、以下の通りです。

• 可能性 - 該当するプラットフォームのユーザにこの問題が生じる可能性

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

• パッチ - この変更が以前にパッチとして配布され、実運用しているシステムで問題なく動作しているかどうかの有無

• 拡張性 - この変更が新機能や拡張機能を提供するかの有無

今回の変更により、新しいサーバを追加したときに、サーバ名およびアドレス・フィールドの一意性が保証されるようになりました。

今回の変更により、コントロール・パネルの問題が修正されました。変更前は、ローカル・データベースを拡張するたびに、ロック・テーブルに新しいエントリが追加されていました。そして、これらのロック・エントリは、コントロール・パネルを閉じないと削除されませんでした。今回の修正により、拡張を終了すると、ロックが解放されるようになりました。

Web ページに以下のようなフォームがあるとします。

<form name=form1 method=post action='textarea.csp'>
<textarea name=txt rows=15 cols=100 value="">
</textarea>
<br><input type=submit name="btn" value="Submit">
</form>

このテキスト・エリアに 32 KB を超えるデータが含まれる場合、CSP サーバはクラッシュしていました。今回の修正により、すべてのデータを保持するストリームが作成され、%request.Data("txt",1) にアクセスすると、ストリーム oref が取得されるようになりました。これは、32 KB を超える可能性があるすべてのフィールドに対して、以下のようなコードを記述する必要があることを意味します。

Set value=%request.Data("fieldname",1)
If $isobject(value) {
  ; Treat this as a stream
} Else {
  ; Treat this as a regular string
}

今回の変更前は、JavaScript のブーリアン値を #server 引数または #call 引数として渡すと不整合になりました。#call または #server によって渡されるブーリアン値は "true" または "false" ですが、IE の Java アプレット・ベースの #server はこれらの値を -1 または 0 として渡し、Mozilla の Java アプレット・ベースの #server はこれらの値を "true" または "false" として渡します。上位互換ソリューションに整合性がないため、true または false を 1 または 0 として渡すという、最も Caché に近いソリューションを実装しました。

この変更の実装は、ユーザが必要に応じてこの変更をバックアウトするのを大幅に簡略化する目的で設計されました。JavaScript のブーリアン値の調整は、<CacheDirectory>/csp/broker/cspbroker.js. にある JavaScript 関数の cspMakeBoolean を使用して行います。この関数のコメントには、機能を以前の不整合なモデルに戻す方法が説明されています。

#call または #server によってブーリアン値引数を渡す場合、プログラマはアプリケーション・コードを調整する必要があります。この場合は、コードをスキャンして "true"、"false"、または -1 に該当する箇所を調べ、Caché のブーリアン値として 1 または 0 を期待するように変更します。

今回の変更により、IIS ルートへのパスにピリオドが含まれる場合に、ゲートウェイのシステム管理が動作しない問題が解決されました。例えば、以下のようになります。

C:\Inetpub\www.com\Website

このパスを使用してシステム管理を呼び出すと、'www.com' の箇所がシステム管理フォームに対する要求を識別するゲートウェイのロジックにとって混乱を招くものとなるため、'Invalid Request' エラーがブラウザに返される結果となりました。

一般的に、Web リソースへのファイル・パス (ディレクトリ名の中) にピリオドがある場合、あいまいさと混乱の原因となる可能性があります。このことは、CSP ベースのリソースではよくあることですが、問題のエンティティが仮想である場合に特に当てはまります。

%Net.POP3 の StoreAttachToFile プロパティが true の場合、添付ファイルは AttachDir で指定されているディレクトリに保存されます。添付の有無は、"Content-Disposition=attachment" ヘッダによって示されます。以前は、content-disposition ヘッダに filename 属性が指定されている場合にのみ、ファイルが保存されました。

現在は、%Net.POP3 によってすべての添付ファイルが、次に示すファイル名を使用して保存されるようになりました。

1. Content-Disposition の filename 属性にファイル名が指定されている場合は、その名前を使用する。
2. Content-Type の name 属性にファイル名が指定されている場合は、その名前を使用する。
3. それ以外の場合は、ATTxxxxxx.dat という形式の一時的な名前を生成する。

今回の変更前は、SQL マネージャを介してチューニング・テーブルを実行すると、エクステント・サイズの計算結果がゼロの場合でも、選択関数が呼び出され更新されました。今回の変更により、エクステント・サイズの計算結果がゼロの場合 (データがない場合) は、選択関数が呼び出されず、結果として変更がテーブルに保存されなくなりました。この場合、以下のようなメッセージが表示されます。

Table extentsize = 0. No changes will be made.

今回の変更により、ルーチン・インデックス・グローバルは、必要なときにのみ再構築されるようになりました。変更前は、インデックスがしばしば不必要に再構築され、パフォーマンス低下の原因となっていました。

今回の変更により、異なるノード上で実行されている Caché とのインストールの競合が回避されました。この変更は、UNIX および OpenVMS でのインストール手順に適用されます。

GOTO コマンドの引数として $CASE 関数を使用すると、ルーチンのコンパイル時にアクセス違反が生じたり、実行時に予期しないエラーが生じることがありました。今回の変更により、この可能性は修正されています。

$ZSORT() 関数の 2 番目のパラメータが無効な場合に $ZSORT() 関数をコンパイルすると、アクセス違反が生じることがありました。今回の変更により、この問題は修正されています。

今回の変更により、ECP リカバリの失敗の原因となっていたラベルのタイプミスが修正されました。

OpenVMS 上の Caché では、LAT セッションを開始または停止するたびに、SYSLOG エントリがログ記録されました。今回の変更により、セッションの開始と終了に関してはログが記録されなくなりました。

複数の構成要素を持つ ID 値を使用して %OpenId を呼び出したときに、その構成要素の 1 つが NULL の場合は、ID 値が無効であることを示すエラーが返されます。

例えば、クラス A は永続的で、P1 と P2 という 2 つのプロパティを持つとします。P1 と P2 には、idkey インデックスがあります。##class(A).%OpenId("abc||") は成功せず、ID の構成要素値の 1 つが NULL であることを示すエラー・メッセージが表示されます。

これまでは、<SUBSCRIPT> エラーが返されました。

クラス内に作成された一意性制約は、サブクラスに継承されると制約の作成元が SQL に投影されないため、適切に強制されませんでした。

現在は、SQL に投影されるすべての未修飾クラス名が、制約作成クラスとして修飾されます。

IDKEY (ROWID とも呼ばれる) は、単一の値か、"||" で区切られた複数の値のどちらかです。この値が別クラスへの参照で、その参照にも "||" 文字が含まれる （参照先のクラスに複数のプロパティに基づく IDKEY がある） 場合、Caché は、IDKEY の各構成要素値に予想される "||" 文字の数を追跡する必要があります。Caché は、その情報に基づいて、$PIECE を使用して個々の IDKEY 構成要素値を抽出します。

クラスが子であり、その親の IDKEY が複数プロパティに基づいているときに、親のプロパティの 1 つまたは複数が別の永続クラスへの参照で、その参照先クラスの IDKEY もまた複数プロパティに基づいている場合は、ストレージ・コンパイラによって、データを保持するための正しいコードが生成されない場合がありました。これは、すべての親プロパティ (識別情報プロパティ) に構成要素値が含まれないことを前提としていたためです。

この問題は、修正されています。

継承された一意性制約は、SQL によって適切に実施されませんでした。例えば、クラス A が永続クラスで、インデックス I1 が作成されたプロパティ P1 を持つとします。P1 には一意性が定義されています。

さらに、クラス B がクラス A を継承するとします。

今回の変更前は、クラス A 内に既存する値を P1 に指定して、クラス A に行を挿入すると失敗しました。一方で、P1 の値がクラス A 内の行に既存しても、クラス B への不適切な SQL insert は成功しました。

この問題は、修正されています。

一意性制約がサブクラスによって継承されている場合に、ベース・クラスで定義されている一意性制約を侵害するような INSERT がサブクラスのテーブルで許可されるエラーが修正されました。

上書きされた完全な行参照がインデックス・マップに使用されている場合に、インデックス・マップで正しいファイリング・コードを生成できないという SQL テーブル・コンパイラの問題が修正されました。

また、インデックスが以下のような構造で定義されている場合に、テーブルの任意の行のフィールドに値が存在するかどうかを決定するコードで正しいコードを生成できないという SQL テーブル・コンパイラの問題も修正されました。

^[$Piece(LVar({F1}),",")]Glo("a",{F1},{ID})

これらの問題のどちらの場合も、テーブル・ファイリング・ルーチンに対して不正な構文が生成されていました。

挿入先のテーブルに挿入列リストに指定されていないストリーム・フィールドがある場合に、INSERT/SELECT 文が <INVALID OREF> エラーでクラッシュするエラーが修正されました。

プリプロセッサのエラー・トラッピングで <UNDEFINED> エラーが生じ、通知しようとしている本当のエラーを隠してしまうという Caché マクロ・プロセッサの問題が修正されました。

ビューのクエリの WHERE 節にサブクエリがあるビューが潜在的に更新可能なビューとして不適切に処理されるため、コンパイル時に <UNDEFINED> エラーが発生するエラーが修正されました。今回の変更により、ビューのクエリにサブクエリがある Caché SQL ビューは更新不能となりました。

今回の変更前は、%CacheSQLStorage を使用したときに、マップ・データのフィールドが親またはそれ以上のテーブルの IDKEY フィールドで、そのテーブルの IDKEY が単一フィールドに基づいている場合に、テーブルでデータのファイリングを行うコードが適切にコンパイルされないことがありました。

この問題は、修正されています。

今回の変更により、DSNConfig の問題が修正され、そのパラメータが Caché 5.0 の次のキーワードを取るように更新されました。

1. User、UserName、または UID
2. PWD または Password
3. Host または Server
4. Port
5. Description
6. Namespace または Database
7. Unicode SQLTypes
8. Static Cursors
9. Query Timeout

これらのキーワードの大文字/小文字は区別されません。

キーワードを定義しない場合、UID と PWD 以外は適切な値が割り当てられます。

これらを ConfigDSN API に渡すには、keyword=value の各ペアの間に "\0"区切り文字を使用して、文字列を構成する必要があります。エントリ全体の最後には、2 つの "\0" を記述する必要があります。ConfigDSN の使用方法の詳細は、マイクロソフトのオンライン・ドキュメントを参照してください。

以下に、この文字列の例を示します。改行は読みやすくする目的で挿入されています。

DSN=Testing\0
    Namespace=User\0
    Host=myhost\0
    Port=1976\0
    Description=My own private server\0
    UID=someone;Pwd=passwd\0\0

これまでの GROUP BY または DISTINCT を使用するクエリに対する実行速度の向上がさらに拡張され、より多くのケースに適用されています。また、特定のクエリの実行時に、NULL 値を含むインデックス付きプロパティで <SUBSCRIPT> エラーや無限ループが生じるなどの問題が発生していた一部のケースでも、正しく動作するようになっています。

今回の変更により、TOP および ORDER BY の指定時に、一時ファイルを作成しないアクセス・パスの選択が優先されます。これによって、クエリを満たすすべての行を返すのに最も高速であると判断されたアクセス・パスが選択されるのではなく、ORDER BY に一致するインデックスを使用するなどの方法によって、最初の数行がより高速に返されるアクセス・パスが選択されます。

以下のような文で発生していた問題が修正されました。

SELECT OPTION LOCK_TIMEOUT = 30

この文は、動的クエリの使用時に、Prepare を実行しないことがありました。

以下のような状況で発生していたエラーが修正されました。

INSERT INTO MyTable1,... (MyStreamField1)
    SELECT MyStreamField2,... FROM MyTable2

この文は以下のようなケースで、SQLCODE=-400 エラーが発生しクラッシュすることがありました。

INSERT INTO MyTable1,... (MyStreamField1)
    SELECT 'some literal',... FROM MyTable2

または

INSERT INTO MyTable1,... (MyStreamField1)
    SELECT NULL,... FROM MyTable2

サイズの大きなテーブルをコンパイルするときのテーブル・コンパイラの問題が修正されました。今回の変更前は、生成されたテーブル・ファイリング・コードを複数のルーチンに分割するときに、一部のケースで <UNDEFINED> エラーが発生することがありました。

SQL UPDATE 文でデータが正しく保存されないことがあるというエラーが修正されました。このエラーは、クラスで %CacheStorage が使用されているときに、そのテーブルにおそよ 185 のフィールドがあり、そのすべてがデータ (マスタ)・マップの同じノードに格納されている場合に発生しました。

今回の変更により、SQL マネージャの QueryPlan の URL に "/apps/documatic/" ではなく、"/csp/docbook/" が使用されるようになりました。前者の場合は、余分のライセンスを要することなく、CSP セッションが正しくクリーンアップされます。

今回の変更により、SELECTIVITY に関する問題が修正されました。変更前は、特定の状況でテーブルを切り替えると、プロパティが正しく示されないことがありました。現在は、テーブル・フィールドをロード後に、選択ボックスおよびラベルが NULL に設定されます。これらの 2 つのフィールドは、ユーザが任意の行をクリックすると入力されます。

今回の変更により、<ROUTINE TOO BIG TO SAVE> エラーを受け取ったルーチンの実行を試行したときに起こりうるアクセス違反が修正されました。

今回の変更により、OpenVMS システム上の Caché でオプションの SwitchOSdir=1 が設定されている場合に、ユーザ・ログイン・プロセスの OS ディレクトリが起動ジョブに渡されないという問題が修正されました。

今回の変更により、Caché システムでオプションの SwitchOSdir=1 が設定されている場合に、ユーザ・ログイン・プロセスの OS ディレクトリがジョブ起動ジョブに渡されないという問題が修正されました。

8 ビット・ロケールによって使用される一部の文字セットでは、一部の文字が未定義のままになっています (CP1251 の 0x98 など)。対応する UnicodeLittle および UnicodeBig 変換では、これらの未定義文字は '?' にマップされていました。この機能では、データを失うことなく、CP1251->UnicodeLittle->CP1251 という往復のバイナリ変換を実行できませんでした。

UnicodeLittle はシャドウイングなどの一部の状況でクライアントとサーバ間の通信に使用され、それにはバイナリ・データが含まれる場合があるため、未定義文字が両方の方向でそれ自身にマップされるように、UnicodeLittle および UnicodeBig 変換が変更されました。この変更はテキスト・データには影響せず、バイナリ・データの往復変換がデータの損失なく実行可能になります。

対象の文字セットは、CP874、CP1250、CP1251、CP1252、CP1253、CP1255、LatinG、および LatinH です。

GCOMPACT では、グローバル間を除き、スイッチ 10 または 13 が設定されているかどうかがチェックされませんでした。そのため、GCOMPACT が実行されている場合、システムが静止するまでの待ち時間を設定された BACKUP などのアクティビティが失敗することがありました。

GCOMPACT は、グローバルを処理している間にスイッチをチェックすることで、スイッチが設定されている場合により迅速に休止するよう更新されました。

エラーがある場合に正常な完了を待機する内部的な再試行ループが、UNIX プラットフォームでの fsync() 呼び出しに追加されました。fsync() は、データベース拡張時のジャーナル・ファイルへの書き込みや、データベース・ブロックを WIJ と cache.dat ファイルに書き込み UNIX バッファ・プールをディスクにフラッシュ・アウトするために UNIX で使用され、書き込み内容の一貫性を保証します。

UNIX システムでの 8 KB データベースに対するファイル拡張時にデータをディスクに同期するオペレーティング・システム呼び出しが強化され、特定の種類のデバイスで起こりうる問題が回避されるようになりました。今回の変更前は、この種の問題は、新しく割り当てられたブロックに対して十分なディスク領域がなかったにもかかわらず成功したとみなされた拡張の後で生じており、書き込みデーモンで生じた重大なディスク書き込みエラーとして表示されていました。

今回の変更により、新しいグローバル・ポインタ・ブロックが間違って 0 に設定されることがなくなりました。

異なるネットワーク・ノード上にある Caché 構成の同時スタートアップを防止する機能が Caché に追加されました。この機能は、クラスタ・メンバのような、異なるマシンにインストールされている、同一の物理ディレクトリを共有する構成に適用されます。

今回の変更により、そのディレクトリがローカル・ノードではなく異なるノードで既に使用されている場合は、Caché の起動または停止がブロックされます。この機能では、データベースのマウントに対する保護や、マシン間の共有ファイルシステムで使用されているファイルへのアクセスに対する保護は提供されません。これらはユーザまたはアプリケーションの責任です。

ccontrol "リスト" および "すべての" コマンドが、異なるネットワーク・ノードによって使用されている構成を識別するように変更されました。

このスタートアップの競合回避メカニズムでは、スタートアップ時に cache.ids ファイルにシステム (またはノード) 名が記録されます。そのため、Caché 構成を保持する物理ファイルシステムを共有するすべてのマシンは、一意な名前を持つ必要があります。UNIX では、この名前は hostname コマンドによって返されるインターネット名ではなく、uname -n コマンドによって返されるノード名になります。前者と後者は異なるものになる場合があります。

今回の変更により、JOB サーバでのメモリ・リークや、JOB サーバでの既知の問題の原因となっていた COM ポート操作時のエラーが修正されました。

今回の変更前は、257 以上のデータベースがマウントされている Caché インスタンスで Caché バックアップを実行すると、特定のデータベースのラベル・ブロックおよび増分ビットマップ・ブロックによって他のデータベースのブロックが上書きされる場合がありました。この問題は、OpenVMS と Tru64 UNIX を除くすべてのプラットフォームの Caché 5.0 に該当しました。

^ZSTU ルーチンが長時間実行されたために Caché の起動に長時間 (10 分を超える時間) がかかった場合に、Windows イベント・ログに報告された、ユーザを混乱させる間違ったエラー・メッセージが削除されました。変更前は、以下のメッセージが報告されていました。

Cache service process creation failed, child did not return;
Cache configuration CACHE error: 997.
Cache Control Service Startup failed; Cache configuration CACHE: .

実際は Caché の起動に成功しているため、このメッセージは間違っています。

今回の変更により、コントロール・プロセスがクラッシュした場合に Caché プロセスでイベントを利用できなくなるため、Windows システムで cforce がプロセスを終了できなくなる問題が修正されました。現在は、すべてのイベントが利用不可能な場合でも、cforce はプロセスを停止します。

今回の変更により、シャットダウン時に cforce がクリーンに終了できないジョブの強制終了に失敗し、cstop または cforce の実行後もジョブが残ってしまう場合があるという問題が修正されました。

ECP デーモンは低い優先度で実行されていました (Windows では 5、UNIX では 2)。今回の変更により、ECP デーモンは標準的なユーザ優先度で実行されるようになりました (Windows では 7、UNIX では 0)。

今回の変更により、$DATA(^global,variable) によって間違った結果が返されるエラーが修正されました。このエラーは、グローバルが新しい形式 (8 KB ブロック) のデータベースに格納されており、$DATA の 2 つの引数が未定義だが下位要素を持つトップレベルのグローバル・ノード上で使用されているときに生じました。

現在は、適切な値である 10 が返されます。変更前は 0 が返されていました。

DCP サーバに DCP クライアントからのロックが保持されているときに、DCP サーバがシャットダウンおよび再起動されると、クライアントからサーバへのロック情報のアップロードが失敗するため、DCP クライアント上のロックが 'Lost' ステータスになることがあります。

この問題は、修正されています。

今回の変更により、ECP サーバ・ノードでスイッチ 10 または 13 がオンになっているとき (Caché バックアップの場合など) に ECP クライアントがサーバ・ノードをロックすると、ロック・メモリが破壊されるという問題が修正されました。以前は、子ノードが既にロックされているときに親ノードをロックしようとした場合にのみ失敗しました。

今回の変更により、バックアップをリストアする $$EXTSELCT^DBREST で、非インタラクティブ API の問題が修正されました。一部の状況で、ディレクトリ・リストにリストア・フラグが設定されていない (複数データベースのバックアップ・アーカイブのリストアから除外されている) データベース・エントリをスキップしようとしたときに <UNDEFINED> エラーが報告されていました。

今回の変更により、スタートアップ時にシャドウの起動が構成されている場合にスタートアップを開始すると <UNDEFINED> エラーが生じる問題が修正されました。

今回の変更により、%RI の使用時の問題が修正されました。今回の変更前は、オブジェクト・コードのみのルーチンに対して意図しない上書きが実行されることがありました。今回の変更により、[Compile?] に [YES]、[Replace?] に [NO] を指定したときに、オブジェクト・コード・バージョンのルーチンがまだ残っている場合は、ルーチンのロードが拒否されるようになりました。

今回の変更により、^mtemp インデックスが不整合になった場合に、間違ったルーチン・リストがルーチン・ユーティリティによって生成される問題が修正されました。

今回の変更により、コア・イベント・ブローカー (EB) サービスにおける例外処理メカニズムと自動リカバリ・メカニズムが向上および拡張されました。コア・イベント・ブローカー・サービスは、主にポート 7001 をリッスンする専用の TCP サービスで、EP 操作の非 HTTP モード (例えば、モード 0) で使用されます。

今回の変更は、実運用しているシステムで EB サービスが予期せず停止してしまう問題によるものです。

このバージョンの Caché では、不可避な問題の修正に加えて、製品の特定の領域で強化が行われています。以下に、これらの強化について領域別に要約します。

今回リリースの Caché バージョンでは、タイ語およびアラビア語のロケールに対するサポートが追加されました。

Caché SQL およびオブジェクトに対して、数多くの変更と拡張が行われました。以下に例を示します。

• Java
  
  • Caché データタイプを、対応する Java ラッパー・データタイプ (java.lang.Integer、java.lang.Double、java.lang.Boolean など) にではなく、プリミティブな Java データタイプ (int、double、boolean など) にマップする新しいクラス・フラグが追加されました。
  • Caché コレクションを Java コレクション・フレームワークのインスタンスとして投影するフラグがクラス定義に追加されました。例えば、配列は java.Util.Map のインスタンスとして、リストは java.Util.List として投影されます。これによって、com.intersys.classes.ListOfDataTypes などの古くなったクラスを使用したときに生じる、使用を推奨しないことを伝える警告が回避されます。
  • あらゆる永続クラスの投影に使用する addToBatchInsert メソッドおよび executeBatchInsert メソッドが生成されるようになりました。バッチ操作とバルク操作のスピードが向上し、操作対象のバッチのサイズによる影響を受けなくなりました。
  • %ResultSet インスタンスを返す Caché メソッドを、java.sql.ResultSet インスタンスを返すように投影できるようになりました。これによって、Java バインディングによる Web サービスの利用がさらに効率的になります。
  • Database インタフェースに closeAllObjects メソッドが追加されました。このメソッドは、データベースそのものを破壊することなく、オープンされているすべてのオブジェクトをクローズします。
  • JDBC が変更され、メソッド呼び出しから複数の ResultSets を返せるようになりました。
  
  
• %server
  
  • %server が大幅に改訂および強化されました。
  • %server に対するデバイス・バッファ・サイズが 64 KB に拡大されました。
  • Java では、%qserver のかわりに %server が使用されます。
  • エラーの報告機能が改善されました。
  • 静的カーソルの使用がサポートされるようになりました。

• その他
  
  • 更新 操作を行うキャッシュ・クエリに対するデータの保持に、^CacheTemp が使用されなくなりました。
  • %Library.SQLCatalog.SQLFields() クエリに、新しい列 ORIGINATING_PROPERTY が追加されました。この列には、SQL フィールドに対応する Caché クラス・プロパティの名前が格納されます。
  • SQL_MAX_ROWS オプションが指定されている箇所での JDBC setMaxRows/getMaxRows および ODBC SQLSetStmtOption/SQLGetStmtOption が完全に実装されました。このオプションは、結果セットに含まれる行数を制限します。今回の変更前は、ResultSet のプルーニングはクライアント・サイドで行われました。現在は、プルーニングがサーバ・サイドで行われるようになり、クライアント・サイドでの効率性とメモリの使用効率が向上しました。

今回リリースされた Caché バージョンは、Macintosh OS X 10.3 にインストールしてネイティブに実行できます。インストール・キットは、PackageMaker によって生成される標準の".dmg" ディストリビューションです。

このバージョンの Caché では、データベースまたはデータベースを保持するディスク・ボリュームが一杯になった場合の状況処理に数多くの変更が加えられ、その機能が向上しています。変更内容の中で、重要なものを以下に示します。

• UNIX システムでは、CACHETEMP データベースをホストするファイルシステムが一杯になったときに CACHETEMP にアクセスすると、ジョブが <DATABASE> または <DISKHARD> エラーを受け取ることがありました。現在は、CACHETEMP が満杯になると、ディスク・ボリューム上またはデータベース内のスペースが解放されない限り、ジョブは <FILEFULL> エラーを受け取ります。未使用のグローバルに KILL を実行して(例えば、存在していないジョブから)、データベース内にスペースを作成する場合は 、書き込みに失敗したすべてのブロックで書き込みが成功するか (ディスク上のスペースが使用可能になったため)、関連するブロックが KILL されないかぎり、CACHETEMP からのブロック割り当ては許可されません。コンソール・ログには、システムが書き込みを試行したディスク・ブロックのリストが記録されます。
  
  
• 今回の変更により、データベースの拡張後に、ディスク (または、最大サイズが指定されている場合はデータベース) に残っている使用可能スペースがチェックされるようになりました。スペースが少なくなった場合は、cconsole.log 警告が生成されます。単一ディスク上に複数のデータベースがある場合は、データベースごとに固有の警告セットが生成されます。
  
  
• 書き込みが予定されているデータベース・ブロックがバッファ管理キューの最下部にドロップ・ダウンしたときに生じるパフォーマンス問題を軽減する強化が実装されました。この強化は、LRU キューの最下部に移動された遅延バッファをそのキューから削除して、通常の書き込みデーモンのキューに配置し、次の書き込みデーモン・パスで書き込むことで実行されます。

今回のバージョンでは、ジャーナル・リストアがより堅牢になりました。変更内容の中で、重要なものを以下に示します。

• 最新のジャーナル・ファイル名と名前が照合し、その名前が YYYYMMDD.NNN で終了しないファイルが存在する場合に、ジャーナル・リストアで適切な開始ファイルが選択されるようになりました (OpenVMS 上のトレーリング・バージョン # を除く)。

  以前のバージョンでは、ジャーナル・ファイルの名前として、最新ではない (間違った) 名前が選択されていました。
  
  

• 一部の稀な状況下で、高速モード (ブロック・モードとも呼ばれる) のシャドウが、Caché の起動後に最初にメイン・サーバ上でマウントされた新しいデータベースからの更新の適用に失敗することがありました。この問題は、あらゆるプラットフォーム上のこれまでのすべての Caché バージョンで見られました。今回のリリースで、この問題は修正されています。
  
  
• このバージョンで、シャドウとサーバが “異なる” オペレーティング・システム上で実行されている場合に、シャドウ・ジャーナル・ファイルのパージに失敗するという問題が修正されました (この修正の文脈では、各種 Windows を同じオペレーティング・システムとみなし、各種 UNIX を Linux も含めて同じオペレーティング・システムとみなしています)。
  
  
• 以前のバージョンでは、稀なケースですが、ジャーナル・デーモンがジャーナル・ファイルのオープンに失敗すると、ジャーナル・デーモンが終了しました。これに対する唯一の回復策は、Caché を再起動して、ジャーナル・デーモンを再起動することでした。今回の変更により、ジャーナル・ファイルのオープン失敗が I/O エラーとして処理されるようになり、問題が修復されている間もジャーナル・デーモンはアクティブに維持されるようになりました。
  
  
• クラスタの最後のノードがクラッシュした場合にクラスタ (クラスタの第 1 ノード) を再起動すると、クラスタ・ジャーナルがリカバリされ、クラッシュ時にオープンされていた (コミットされていない) すべてのトランザクションがロールバックされます。

  このバージョンでは、このケースのロールバックがクラスタ・ジャーナル・リストアまたはクラスタ・シャドウイングに認識されず、リストアされたデータベースまたはシャドウ・データベースに間違った結果が生成される可能性があるという問題が修正されました。
  
  

• このバージョンの Caché では、ジャーナル・リストアの最後に、ジャーナル・リカバリ中のより詳細な操作状況メッセージが表示されます。最初に、ジャーナルからすべてのレコードの読み込みが終了すると通知され、その後は、ジャーナル・レコードのデータベースへの適用の進行に従って、それが完了するまで進行状況メッセージが表示されます。

  以前は、すべてのレコードの読み込みが終了したときに、データベースに未適用の段階で、ジャーナル処理が完了したと間違って通知されていました。

---

Copyright  © 1997-2004, InterSystems Corp.

最終更新日 : 2004-0719