Caché 2010.2

新規データベース ： CACHE

このバージョンでは、Caché で使用される標準セットに新しいデータベースが追加されています。そのデータベースは “CACHE” という名前で、キャッシュされた SQL クエリや CSP セッション情報などの情報を保持します。詳細は、"システム管理ガイド" の情報を参照してください。

データベースのマウントに必要な照合およびリソース

データベースをマウントする場合、既定の照合が使用可能かどうかチェックされるようになりました。使用可能でない場合、マウントは失敗します。こうしたことがシステムの起動時に発生した場合、データベースが [開始時にマウントが必要] と指定されていると、Caché は起動しません。その場合、構成からその要件を削除して再起動します。cconsole.log には、データベースのマウントとその既定の照合に失敗したことを示すメッセージが記録されます。

データベースに対して指定されたリソースが使用できない場合も、データベースのマウントに失敗します。こうしたことは、古いシステムをアップグレードする際に発生する場合があります。

8 KB データベースへの自動アップグレード

このバージョンにアップグレードする場合、2 KB の CACHESYS データベース・ブロック・サイズが検出されると、アップグレード時に自動的に 8 KB に変換されます。

通信を保護するための SSL の有効化

Caché は、SSL を使用して外部のエンドポイントとの通信を保護するように構成できます。将来のリリースでは、完全な管理用インタフェースが提供されます。サイトで低レベル・システム設定によりこの機能を有効にする場合は、インターシステムズのサポート窓口Opens in a new tabに“Windows のクライアント側の SSL 設定” についてお問い合わせください。

OpenVMS での $ZF 呼び出しに必要な特権の変更

OpenVMS システムでの $ZF 呼び出しが、本来の意図よりも多くの特権によって実行されるエラーが修正されました。これによりアプリケーションが影響を受ける場合は、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

Tru64 でサポートされない Java

このバージョンの Caché では、Java VM のバージョン 1.4 はサポートされなくなりました。HP Tru64 UNIX® での Java VM のサポートは、バージョン 1.4 が最後となりました。Java 仮想マシンを実行する必要がある場合は、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

現在 Tru64 で仮想マシンの新しいバージョンのサポートを受けるには、GNU GCC ツールセットを使用して OpenJDK ソースをコンパイルするほかありません。

Windows のインストールにパケット・ドライバが含まれない

このバージョン以降では、DDP がサポートされなくなったため、パケット・ドライバ (ispktd2k.sys) は配布されません。また、LAT のサポートも終了しました。

エラー・トラップの入れ子の厳密化

以前のリリースでは、$ZTRAP の設定値の最初の文字がアスタリスクであるか、$ZTRAP が %ETN に設定されていると、より深い実行レベルでエラー・トラップに $ETRAP または TRY/CATCH が設定されていても無視されていました。このリリースでは、最近のエラー・トラップが常に優先され、エラーが発生すると最初に呼び出されるようになりました。

一部の <MAXSTRING> エラー・ケースの <SUBSCRIPT> エラーへの修正

このバージョンの Caché では、ロックの添え字に 256 バイトを超えるエンコード文字列があると、<SUBSCRIPT> エラーが正しく返されるようになりました。以前は、そのような場合に誤って <MAXSTRING> エラーが報告されていました。

日本語ロケールでの既定の $ZDATE/$ZDATEH 形式の変更

日本語ロケールでの既定の日付形式は 1 になりました (以前は 3)。ロケール形式が有効な場合、$ZDATE/$ZDATEH 関数でこの形式が既定で使用されます。この形式は設定によって変更できます。

^SYS("NLS","Config","LocaleFormat")=1

ドイツ語で追加された新しいロケール

サイトで使用するロケールを German Latin1 ベースのロケール (deu8) から同等の Latin9 ベースのロケール (dei8) に移行しやすくするために、dei8 では古い German1 と German2 の照合が使用できます。これらの照合では dei8 と deu8 がまったく同じようにバイナリ・エンコードされますが、ユーザは次の点に注意する必要があります。

1. Latin9 では、Latin1 からほとんど使用されていなかった 8 つの文字 (164、166、168、180、184、188、189、190) が新たに定義し直されています。最も目に付きやすいのは、現在のユーロ記号となっている $C(164) です。deu8 で使用されていたグローバルの添え字で、これらの文字のいずれかを含むものは、Latin9 で解釈されたバイナリ値として表示されます。

2. dei8 の既定の照合は German3 です。サイトで既定の照合を German2 または German1 にする必要がある場合、起動時に設定するか、希望の既定照合でカスタム・ロケールを作成する必要があります。

スロベニア語の新しいロケール

スロベニア語の新しい Unicode ロケールを使用できるようになりました。これには、Slovenian1 照合が含まれ、その内部コードは “svnw” です。

^%SYS 内でのソース・コントロール設定

ネームスペース内で使用するソース・コントロール・クラスを決定する設定はユーザ・データベース・ファイルの ^SYS("SourceControlClass") に保存されていました。しかし、これでは、このデータベースへの書き込みアクセス権を持つユーザがこの設定を変更できてしまうことになります。そのため、この値は ^%SYS("SourceControlClass", <namespace>) に移動されました。この設定を変更するには、CACHESYS データベースにアクセスする必要があります。

これまで、ソース・コントロール・クラスを検索する場合は、^%SYS("SourceControlClass", <namespace>) が常に検索パスに含まれていましたが、この機能は今後も古いバージョンの Caché では有効です。クラスを更新するメソッドは、このノードを設定して ^SYS("SourceControlClass") ノードを消去するように変更されました。

また、ソース・コントロール・パスを検索する場合、検証される場所は次の順に変更されています。

1. ^%SYS("SourceControlClass", <namespace>)

2. ^SYS("SourceControlClass")

3. ^%SYS("SourceControlClass")

マクロ・プロセッサの返り値の変更

このバージョンでは、SQL 文を含むコードをコンパイルする際のマクロ・プロセッサの動作が変更されています。以前のバージョンでは、SQL 文がコンパイルに失敗すると、プリプロセッサはエラーを報告して停止し、コードは生成されませんでした。

このバージョンでは、エラーは報告されますが、コードのコンパイルは続行され、プリプロセッサの呼び出し元に結果が返されます。SQL 文がコンパイルに失敗した場合、次のようなコードが生成されます。

  X "** SQL Statement Failed to Compile **"

エラーのある SQL 文を含むメソッドまたはルーチンを実行すると、その SQL 文を実行しようとしたときにエラー・メッセージが出力されます。この変更により、コンパイルに失敗する埋め込み SQL 文が含まれるメソッドを持つクラスをコンパイルすると、エラーが報告されてもメソッドは生成されるようになります。

BuildValueArray の Final のマーク

プロパティ要素とキーを使用してサブ値インデックスを定義できます。プロパティがコレクションの場合、要素値はコレクションの要素に対応し、キー値は (リストの) 位置または (配列の) キーに対応します。コレクション以外のプロパティでは、要素とキーは添え字と値に対応し、"値配列" に格納されます。値配列は、プロパティ・メソッド BuildValueArray で作成されます。

アプリケーションで BuildValueArray をオーバーライドした場合、オブジェクトを保存するときに結果は無視され、インデックスは更新されませんでした。これは、適切な動作とは言えません。

このリリース以降、BuildValueArray がコレクション・プロパティに対して自動的に生成され、Final とマークされるので、サブクラスでオーバーライドされることはなくなります。

%Text のハイフンおよび負数の解析の向上

このバージョンの Cache' ではハイフン/マイナス記号の解析の向上が図られており、“–<digits>” が負数として解析され、“–<digits>–” が正数として解析されます。 また、“Section 3-4.2-2” などの複雑な非数値文字列は “Section 3 4.2 2” と解析されるようになりました。すべてが数値文字だからといって文字列 3-4.2-2 が数値として扱われることはありません。

このような %Text.Text の解析の変更の結果、場合によっては “–” を含む数値テキスト文字列の解析が異なった方法で処理される可能性があります。そのため、このようなテキストを含むフィールドのインデックスは再構築する必要があります。

LogicalToStorage および StorageToLogical への変更

LogicalToStorage および StorageToLogical は、データ型クラス内で、またはそのプロパティを含むクラスの複合メソッドとしてプロパティに実装可能なメソッドです(プロパティに両方のメソッドを実装する必要はありませんが、メソッドが定義される場合、そのメソッドは実行可能でなければなりません)。LogicalToStorage メソッドは、論理値を保存するときに呼び出されます (シリアル・クラスの場合はシリアル化されたオブジェクトに配置され、永続クラスの場合はディスクに書き込まれます)。StorageToLogical は保存された (またはシリアル化された) プロパティ値を保存されたオブジェクトから抽出して論理コンテナ (通常はプロパティのインスタンス変数) に配置するときに呼び出されます。

以前のバージョンでは、コレクションに適用する場合、ターゲット・メソッドにコレクション全体が提供されていました。このバージョンでは、メソッドはコレクションの要素ごとに一回呼び出されます。

%SQL.StatementMetadata への変更

%SQL.StatementMetadata クラスでは、ダイナミック SQL 文の文メタデータをモデル化します。メタデータ・インスタンスは、objects プロパティを持ちます。このプロパティは、いくつかのクラスのインスタンスを参照する ID 値を持つ列の特性を記述するインスタンスのコレクションです。StatementObject クラスの構造は、StatementColumn と StatementObject をリンクしやすくできるように変更されました。

以前は、StatementObject は columnName、extentName、および exportCall の各プロパティで構成されていました。StatementObject の定義には、新しく整数の column プロパティが含まれるようになりました。これは、列コレクションの要素番号に対応します。

クラスの削除

2010.1 バージョンに存在していた以下のクラスは、今回のバージョンで除外されています。

• %JavaScript パッケージ – Object、Runtime

• %SQL パッケージ – StatementCache

• %XSQL.DSI パッケージ – JPAQuery

• %cspapp.mgr パッケージ – utilconfignethome、utilsysnetworklegacy

• Config パッケージ – DDP、DDPVolumeAndUCIs、DDPVolumeSets、DTMnetBIOS、ETHServers、LAT、LATServices、Config.MirrorReportingAuthorizedIDs、Config.MirrorReportingSources、Net、Servers、UDPServers

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

以下のクラス・コンポーネントは、インターシステムズで使用するために予約されているため、アプリケーションでは呼び出さないでください。

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

このバージョンでは、以下のクラス・コンポーネントが、以前に存在していたクラスから移動または削除されています。

メソッド返り値の変更

今回のバージョンの Caché では、以下のメソッド返り値が変更されました。

• %CSP.UI.Portal.Config.ZenReport パッケージ – SaveData

• %ResultSet.Result パッケージ – %Display

• %SYS.Journal.SetKillRecord パッケージ – ExistsOldValue

• %SYS.TaskSuper パッケージ – FindId

• %UnitTest.Manager パッケージ – GetTestStatus

• %XML.Node パッケージ – GetText

• %ZEN.Template.ObjectGatewayWizard.JavaDone パッケージ – ImportClasses

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

今回のバージョンの Caché では、以下のメソッドの呼び出しシーケンスが変更されました。

インデックスの SQL 名の一意化

インデックスの SQLNAME は一意にする必要があります。この制約は、以前のリリースでは必須ではありませんでした。このバージョンでは、一意かどうかチェックされて一意でない場合はエラーが報告されます。

単純な ID の使用時に必要な正規化

Caché では、単純 ID 値は、ID をパラメータとして取るさまざまなメソッドによって正規化されなくなりました。クラスのさまざまなメソッドに渡される ID 値は <oref>.%Id() メソッドで返される正規化された形式であることが想定されています。ID は単純な整数であるが、渡される値が整数の正規化された形式ではない (例えば、1 ではなく 01 である) 場合、%Open() や %Exists() のようなメソッドは失敗します。

プロパティの Java 生成コードへの変更

新しいオブジェクトのディスパッチにより、2010.1 以降の Java ドライバでは、予測値フィールド ii_<PropertyName>、jj_<PropertyName>、または kk_<PropertyName> を使用しなくなりました。生成されたサンプルを正しく機能させるには、2010.1 以降の CacheDB.jar が必要です。

SQLCODE および %RowCount の名前の変更

特定のクラス (結果セット、プロシージャ・コンテキスト・クラス、および動的な文) には、SQL 文の実行結果を示す値が設定される、SQLCODE プロパティが含まれていました。以前のバージョンでは、このプロパティには別の似た名前がありました。このバージョン以降、%SYSTEM.ErrorOpens in a new tab だけは %SQLCode のままですが、その他すべてのクラスでは %SQLCODE という名前になります。

いくつかのダイナミック文クラスおよび結果セット・クラスには、別のプロパティ %RowCount が存在します。これは、ローカル変数 %ROWCOUNT に対応します。このバージョン以降、すべてのクラスで、このプロパティは %ROWCOUNT という名前になります。

これらのクラスには動的ディスパッチ・メソッドが実装され、既存のコードへの影響が低減されます。動的ディスパッチは、大文字および小文字の形式がさまざまに異なる %SQLCODE および %ROWCOUNT をチェックし、すべて大文字への参照を正規化します。ほとんどの場合は、これによって、何の変更もなく既存のコードを機能させることができるようになります。ただし、パフォーマンスを向上させるには、決められたプロパティ名 %SQLCODE および %ROWCOUNT を使用するように既存のコードを更新するのが最適な方法です。

%ResultSet での列名の修飾

%ResultSet インスタンスで受け取った行タイプ指定に同じ名前の列が複数あった場合、列名に列番号が付けられるように変更されました。

クエリによる TOP の適用

以前のバージョンでは、

SELECT TOP :a <query1> UNION <query2> ...

という形式のクエリでは UNION の結果に TOP が適用されていました。このバージョン以降、TOP はそれが存在するクエリにのみ適用されます。以前のリリースの動作を再現させるには、このクエリを次のように書き換える必要があります。

SELECT TOP :a FROM (<query1> UNION <query2>) ...

SQL コンパイラによるクラス・データへのアクセスの必要性

SQL 文をコンパイルする場合、SQL コンパイラはその SQL 文が使用しているテーブルに対応する任意のクラス定義の共有ロックを取得するようになりました。この共有ロックは、コンパイラが内部メタデータにアクセスする際に取得され、その直後に解放されます。SQL コンパイラがコンパイルに必要なクラスの共有ロックを取得できない場合、エラーが返され (%SQLCODE = 150) SQL 文のコンパイルは失敗します。ロックの試行には、現在の SQLLockTimeout 設定が使用されます。

以前のリリースでは、SQL コンパイラで使用されるメタデータが未完成のためにコンパイルされた SQL 文が正しく動作しないことがありましたが、このロックによりそれが回避されます。

クエリ・キャッシュの変更

このバージョンの Caché では、クエリ・キャッシュの保存および使用方法に多数の大幅な変更が加えられました。最も重要なものは以下のとおりです。

• グローバル ^mcq は、クエリ・キャッシュの保持に使用されることはなくなり、予約されたグローバル名ではなくなりました。クエリ・キャッシュは CACHE データベースに保存され、管理ポータルでのように、ネームスペースを超えて表示されることはありません。

• 一部のクエリ・キャッシュの RS クラス・パッケージは使用されなくなり、予約のパッケージ名ではなくなりました。

• クエリ・キャッシュ・ルーチンでは “CacheSql” ルーチン接頭語が使用されなくなり、予約されたルーチン名ではなくなりました。

• サーバの初期化または切断コードを設定する場合、^mcq("init code") を直接設定することはできなくなりました。代わりに、以下のように API を使用する必要があります。

  • $SYSTEM.SQL.SetServerInitCode(code) ： code には、実行される初期化コードが入ります。code="" を指定するか何も指定しないでこの関数を呼び出すと、このネームスペースの初期化コードが削除されます。

  • $SYSTEM.SQL.SetServerDisconnectCode(code) ： code には実行される切断コードが入ります。code="" を指定するか何も指定しないでこの関数を呼び出すと、このネームスペースの切断コードが削除されます。

• 新しい関数 $SYSTEM.SQL.PurgeAllNamespaces() を使用して、システムのすべてのネームスペースですべてのクエリ・キャッシュを削除できるようになりました。$SYSTEM.SQL.Purge() は、現行どおり、現在のネームスペースのみですべてのクエリ・キャッシュを削除します。

• %SQL.StatementCache クラスは %SYS.SQLStatementCache という名前に変更されました。%SQL.StatementCache は使用されなくなりました。

• %XSQL.DSI.JPAQuery クラスは %SYS.SQLObjectQuery という名前に変更されました。%XSQL.DSI.JPAQuery は使用されなくなりました。

以前のバージョンでは、システム管理ポータルを介して、あるネームスペースのクエリ・キャッシュが別のネームスペースで表示されていました。このバージョンでは、クエリ・キャッシュは個別の場所に保存されるため、ネームスペースを超えて表示されることはなくなりました。

SQL 関数の結果への照合の適用

SQL 関数の返り値が照合値を持つ場合、その関数を SQL 文で呼び出したときに、SQL はその返り値にその照合を使用するようになりました。そのような関数を呼び出すクエリでは、SQL の結果が以前のバージョンとは異なる可能性があります。

次に、その例を示します。この関数が次のように定義されているとします。

Class SQLUser.FunctionTest Extends %Persistent
{
Property myString As %String(COLLATION = "SQLSTRING(100)", MAXLEN = 500);

ClassMethod Reverse(Arg1 As %String) As %String
    (COLLATION="SQLSTRING(100)", MAXLEN=500) [SqlName=Reverse, SqlProc ]
  {
      quit $REVERSE(Arg1)
  }
}

また、次のようなクエリを使用するとします。

SELECT myString, SQLUser.Reverse(myString) gnirtSym 
FROM SQLUser.FunctionTest 
ORDER BY 1, 2

以前のバージョンでは、クエリを実行したときに、myString のデータ長が 500 文字に近づくと <SUBSCRIPT> エラーが発生していました。これは、Caché の既知の添え字長の制約によるものです。このバージョン以降、SQL クエリ・プロセッサは関数の返り値の照合を SQLSTRING(100) として認識し、関数の返り値の照合値で ORDER BY が実行されます。

連結演算子の変更

SQL 連結演算子の動作に小さな変更があります。 以前のバージョンでは、SQL 文に “A || B” という記述があると、結果の値は EXACT 照合による文字列になりました。現在のバージョンでは、A および B が両方とも文字列で、両方に同じ照合があると、結果もその共通の照合のものになります。そのため、クエリによっては返される結果が変わる場合があります。

ラージ・オブジェクト SQL データ型に対する新しい既定の DDL データ型のマッピング

新しいバージョンでは、すべてのラージ・オブジェクトに対する既定の DDL データ型のマッピングが変更されました。

• CLOB (Character Large Objects) は、“CStream%String” から %Stream.GlobalCharacterOpens in a new tab に変更されました。

• BLOB (Binary Large Objects) は、“BStream%String” から %Stream.GlobalBinaryOpens in a new tab に変更されました。

複数のシステムに新しいバージョンを新規インストールまたはアップグレードを実行してセットアップした場合、新規にインストールしたシステムでは、既存の DDL CREATE TABLE 文および ALTER TABLE 文を実行してストリーム・フィールドを作成する際に異なるクラス定義が生成されることがあるので注意が必要です。 BStream%String および CStream%String とその同義語 (%Library.GlobalBinaryStream および %Library.GlobalCharacterStream) は、引き続き完全にサポートされます。

エラーの明示的な表示

以前のバージョンでは、変換が失敗した場合に何もメッセージが表示されませんでしたが、エラー・メッセージが報告されるようになりました。この変更により、切り捨て以外の原因による変換エラーを含む行に SQL_ERROR が返されるようになりました。これは、SQLServer のレポートの動作に合わせたものです。 Caché のより明確なメッセージが使用できる場合、報告される SQL の状態は、SQLServer での表示と異なる場合があります。

エラー・ハンドラで返される詳細情報

SQLError および他のエラー処理 API を呼び出したときに、以前のリリースより詳細な情報が返されます。これらの API は複数のエラーを報告する機能を持つようになり、エラー・レポートで複数のレコードにより状態が示されるようになりました。 そのため、SQLGetDiagRec および SQLGetFieldRec ODBC 3.5 API を呼び出すアプリケーションを通じ、結果セットの特定の行および列での切り捨てエラーを (数あるエラーの中から) 報告することが可能になりました。

ユーザ定義の DATE および TIMESTAMP の処理の変更

以前のリリースでは、以下のように処理されていました。

• アプリケーションにユーザ定義の DATE データ型があり、そのデータ型の論理値が +$Horolog でない場合、このフィールド値の入力として、またはクエリ内のこのフィールドの比較値として、CURRENT_DATE が受け付けられませんでした。また、DATEDIFF、DATEADD、DATENAME、または DATEPART の呼び出しでもこのフィールドは使用できませんでした。

• アプリケーションにユーザ定義の TIMESTAMP データ型があり、このデータ型の論理値が 'YYYY-MM-DD HH:MM:SS[.sss]' でない場合、このフィールド値の入力としても、クエリ内のこのフィールドの比較値としても、または DATEDIFF、DATEADD、DATENAME、または DATEPART の呼び出しでも、CURRENT_TIMESTAMP を使用できませんでした。

Caché SQL では、ユーザ定義データ型クラスにユーザ定義論理値から %Library.Date 論理値に変換するメソッドが含まれていれば、これらの操作がサポートされるようになりました。ユーザ定義の日付データ型クラスに必要なメソッドは、LogicalToDate と DateToLogical です。

SQL ストアド・プロシージャの所有者

ストアド・プロシージャの SQL プロジェクションに変更がありました。 プロシージャの所有者 (プロシージャを投影するクラスの所有者) が特に定義されていない場合、所有者は既定で “_SYSTEM” になり、特権は所有者に付与されません (_SYSTEM には %All ロールがあるため)。 これは、テーブルおよびビューを投影するクラスをコンパイルする際の動作に合わせたものです。 以前のバージョンでは、所有者は既定で現在のユーザ (クラスをコンパイルしたユーザ) になっていました。

クラス参照プロジェクションの変更

CLASSNAME=1 である別の永続クラスを参照するプロパティを含む永続クラスでは、このプロパティは参照として SQL に投影されず、単純な %List 型として投影されるようになりました。これより、このフィールドを処理していた SQL が参照行の ID を含む整数値であった場合の動作が修正されました。ただし、CLASSNAME=1 の場合、フィールド・データは Oid 値となり、整数にはなりません。

新しい EXTERNALSQLTYPE プロパティ

リンクされるテーブルをリンク・テーブル・ウィザードで定義する場合、新しいプロパティ・タイプ・パラメータは EXTERNALSQLTYPE で定義されるようになりました。これは、タイプ番号または外部テーブルのメタデータから返される名前に設定されます。

CAST(x AS NUMERIC(p,s)) の修正の適用

数値の小数点区切りに (ヨーロッパの形式の) コンマが使用されていると、“CAST(value AS NUMERIC(5,2))” は表示モードで誤った結果を返していましたが、この問題は修正されました。

式 CAST (value AS NUMERIC(precision, scale)) では、キャスト値の完全な表示小数桁を含む論理値を返していました。例えば、CAST(1 AS NUMERIC(5,2)) は論理値として 1.00 を返していましたが、単に 1 を返すようになりました。表示値は 1.00 のままです。CAST の結果の論理値が 1.00 になるようにしていたコードは、修正する必要があります。

8 ビット・システムでの文字セットのレポートの変更

8 ビット・システム上の CSP を介してストリーム・サーバによりファイルが処理される場合、Caché では使用されている文字セットがさまざまな方法で報告されるようになりました。以前は、既定の文字ファイル変換テーブルを使用していましたが、8 ビット・システムではほとんどの場合 RAW となっていたため、必要な情報が提供されませんでした。このバージョン以降、これらのファイルについてシステムの既定のロケール文字セットが報告されるようになりました。ロジックは以下のようになります。

1. ^%SYS(“CSP”, “MimeFileClassify”, extension) が定義されると、それは “$LISTBUILD(type, binary, charset)” という形式であると見なされ、このファイルのタイプを報告するのに使用されます。

2. ファイルが文字タイプでない場合、文字セットは常にバイナリ・ファイルの “” に設定されます。

3. ^%SYS(“CSP”, “DefaultFileCharset”) が定義されると、それがファイルの処理で使用される文字セットになります。

4. Unicode バージョンの Caché がインストールされている場合は、既定のファイル文字変換テーブルが使用されます。

5. 8 ビット・バージョンの Caché がインストールされている場合は、システムの既定の文字セットが使用されます。

Caché の文字変換に関する背景情報は、"Caché プログラミング入門ガイド" の “ローカライズのサポート” を参照してください。

CGI 変数 SERVER_NAME

CGI 環境変数 SERVER_NAME が、Caché にディスパッチされる最初の要求データ・ブロックの先頭に配置される一連のフィールドの 1 つに含まれるようになりました。これは、Caché で CSP サーバを有効にして要求処理サイクルの早期にアプリケーションを特定するためです。データ・ブロックの最初の 3 つのフィールドは次のような順序になっています。

1. セッション ID (CSPCHD)

2. CGI 環境変数 SERVER_NAME

3. 要求パス/ファイル (CSPLIB)

安全なページと安全でないページの間でのセッション ID の正しい処理

http リンクでロードされるページ自体に https ページへのリンクがある場合、CSPCHD SessionId が含まれないようになりました。これは、トークンベースのセッション管理が有効な場合や、そのページがセッションの最初のページで自動検出ロジックが有効な場合も同様です。

Caché InitialExpression を使用した XML スキーマ固定属性の表現

Caché では、XML スキーマ・ウィザードで作成された Caché クラスの InitialExpression キーワードを使用して、XML スキーマの要素および属性の固定の属性が示されるようになりました。アプリケーションで固定の要素または属性が指定されているかどうかを判断できるようにしている場合、それを実行することはできなくなります。

XMLImport の効率化

XMLImport は、以前は再帰的にサブツリーを処理していましたが、より効率的に子要素を処理するように変更されました。アプリケーションで XMLImport をオーバーライドしている場合、アプリケーションの処理の一部を再設計する必要がある場合があります。

MIME パーツの処理の修正

このバージョンでは、以前のバージョンでの MIME パーツのメッセージ処理時のエラーが修正されました。WSDL で document/literal および MakeMessageStyle=1 (複数のパーツを許可するメッセージ・フォーマット) を指定した場合、MIME コンテンツに対応するパーツが、<binding> <operation> の soap:body 要素で呼び出された際に作成されるようになりました。以前のバージョンでは、MIME パーツがパーツ・リスト内にあってもパーツ・リストの既定であっても、誤ってすべての MIME パーツが無視されていました。

ICacheObject としての %Stream.Object の投影

以前のバージョンでは、クラスのプロパティまたはメソッドで使用される %Stream.ObjectOpens in a new tab を CacheProvider に投影できませんでした。このリリース以降、これは生成されたコードに ICacheObject として存在します (.NET プロキシ・クラスの一般的なインタフェース)。実行時にクライアントに返される実際のオブジェクトは、特定のサーバ・ストリーム・オブジェクトの投影になります。例えば、実行時に返されるオブジェクトが %Stream.GlobalCharacterOpens in a new tab の場合、クライアント・オブジェクトは CacheCharacterStream になります。

Light C++ バインディングでの独自のネームスペースの使用

このバージョン以降、Light C++ バインディングでは TCP/IP ベースの C++ バインディング ("InterSystems") と異なるネームスペース ("InterSystemsLCB") を使用します。これにより、同じアプリケーションで LCB および TCP/IP ベースの C++ バインディングの両方を使用し、それぞれのバインディングで異なる共有ライブラリ (または Windows の dll) を使用できるようになります。それぞれのライブラリのインストール元または接続先の Cache のバージョンは異なっていてもかまいません。

runMethod の変更

バインディング・サーバ・プロトコルにより、出力リダイレクト内で呼び出しを入れ子にすることができます。以前のバージョンでは、クライアントへの出力リダイレクト呼び出しごとにバインディング・メッセージ・ループへの入れ子の呼び出しが開始され、前のサーバ・メッセージに戻るためにクライアントからの個別のメッセージが必要でした。

この変更により、入れ子の呼び出しの使用は任意となりました。CacheProvider では、既定で runMethod への入れ子の呼び出しが不可能になりました。入れ子の呼び出しを使用するアプリケーションは、明示的に AllowNestedCalls を True に設定する必要があります。

小数桁数が 2 の %Numeric のフォーマットの変更

以前のリリースでは、Access 2000 で “0.00” の値が #deleted と解釈されてしまう不具合の回避策として、0 の値に “.00” が返されていました。今回のリリースではこの回避策が取られなくなったため、Access 2000 を使用しているサイトではそのバージョンをアップグレードする必要があります。

連結結果の切り捨ての廃止

以前のバージョンでは、連結式で 255 文字を超える長さの文字列が生成された場合、255 文字に切り捨てられていましたが、このバージョンでは切り捨てられなくなりました。

バージョン 3.5 ODBC での WVARCHAR SQLTypes と Unicode SQL Types の使用

ODBC 3.5 で文字列に対して WVARCHAR SQLTypes が完全にサポートされるようになりました。 Unicode バージョンの Caché がインストールされている場合は、データ型が Unicode かどうかは重要ではありませんが、DotNet および Access アプリケーションで WVARCHAR をサポートするために ODBC が必要になる場合があります。 以前の Caché では、Access に対して “Unicode SQLTypes” という DSN 定義オプションを使用しており、これを 1 に設定すると、文字列 SQLType に対して 12 でなく -9 が返されていました。

“Unicode SQLTypes” はプログラムによる制御を通じて、または DSN 設定で使用できます。 UnicodeSQLTypes は既定で 0 に設定され、VARCHAR 型に対して 12 が返されます。 この変更により、カタログ・クエリから報告されたメタデータをスイッチに基づき動的に変更できるようになります。 サーバ側では、従来どおりこれらのデータ型が 12 と見なされます。

EQUATE 参照の処理の変更

以前のバージョンでは、EQUATE 定義に対応するソース内のすべての語が定義の本文に置き換えられていました。このリリース以降、EQUATE 定義と一致させるために、“–>” で区切られた一連の語が単一のエンティティと見なされるようになります。例えば、次のような一連の語があるとします。

EQU VIN TO CAR(7)
AutoCheck->VIN = VIN

これは、以前は次のように解釈されていました。

AutoCheck->CAR(7) = CAR(7) 

このバージョンでは、次のように処理されます。

AutoCheck->Vin = CAR(7)

CREATE.INDEX キー長の既定は 150 文字

CREATE.INDEX コマンドで作成されるキーの既定の長さは 150 文字です。アプリケーションで大きなインデックスのキーが必要な場合、開発者はクラスのインデックス定義を手動で編集する必要があります。

セカンダリ・インデックス

INDICES(filevar) は、実際のインデックス名が含まれる配列を返すようになりました。以前は、インデックスが作成された MultiValue ディクショナリが返されていました。これにより、INDICES() 関数が、MultiValue コマンド CREATE.INDEX で作成されたインデックス、およびクラスで直接作成されたインデックスを返すことができるようになります。

INDICES(filevar, indexname) で返される配列に 2 つの新しい属性が追加されました。属性 7 にはプロパティ名、属性 8 には MVName が含まれます。

任意の MultiValue コマンド、および MVBasic 文と関数は、実際のインデックス名または MultiValue ディクショナリ名を受け取ることができるようになりました。

Universe エミュレーションでの変換時の空白の無視

Universe は、文字列を数値に変換するときに、先頭または最後にある空白を無視します。Caché Universe エミュレーションも同様に処理するようになりました。

独立したディレクトリおよびファイルを処理する MVIMPORT の拡張

MVIMPORT は、コマンド行のオプションの 2 番目のパラメータを受け付けるようになりました。このパラメータには任意のディレクトリおよびファイルを保存するパスが指定され、これを指定しないとディレクトリやファイルは VOC に直接関連付けられずにスキップされます。MVIMPORT は、バックアップを確認し、ディレクトリ・ツリー内のそれらすべてのディレクトリとファイルが含まれる最下位の場所を特定します。その後、コマンド行で指定されたパスにそのサブツリーがインポートされます。

スプーラによる同一ジョブでのバイナリ・データとテキスト・データの処理

この変更により、MultiValue アプリケーションはバイナリ・データと非バイナリ・データを同じ印刷ジョブで処理できるようになりました。以前のバージョンでは、(SP-CONTROL で定義した場合) 改ページ文字があると別のシーケンスに変換されるという問題がありました。この変換は、変換が必要なテキスト・データと変換が不要なバイナリ・データの両方で行われていました。今回の変更に伴い、ジョブの開始時に出力される改ページが少なくなるという以前のバージョンの不具合も修正されています。

SQL フォーマットでの既定の有効桁数は 4

2010.1 で導入された SQL の MV フォーマット処理 ($MVFMT、$MVOCONV など) において、MultiValue の既定の有効桁数が 0 ではなく 4 になりました。これは、MV シェルからの動作と同様です。以前のバージョンでは、この値は MV コマンドが発行されるまで初期化されませんでした。

論理演算子のエミュレーションへの依存

MVBasic 論理演算子 “AND” および “OR” は、コンパイルに使用されるエミュレーションに従って正しく動作するようになりました。Universe や jBase などのエミュレーションは、式の結果が判明すると引数の評価を停止します。

必要に応じて、エミュレーションが既定とは異なった動作をするよう制御するために、新たに $OPTIONS オプションが用意されています。

• $OPTIONS FULL.LOGICAL.EVALUATION は、すべてのオペランドが常に評価されることを示します。

• $OPTIONS -FULL.LOGICAL.EVALUATION は、最初のオペランドを評価した後で結果が判明した場合に他のオペランドが評価されないことを示します。

Ultimate の既定は VAR.SELECT

Ultimate エミュレーションの既定は $OPTIONS VAR.SELECT になりました。

非数値文字列の比較の修正

比較関数 EQS、NES、GTS、GES、LTS、および LES の引数に非数値文字列があった場合、それらの文字列がプログラムのコンパイルに使用されるエミュレーションに従って正しく変換されるようになりました。以前のバージョンでは正しく変換されていませんでした。

READPREV の位置の修正

以前のバージョンでは、存在しないキーに対して SELECT ATKEY を実行した後、最初の READPREV で レコードが 1 つスキップされていました。現在は、レコードの位置が正しく処理され、レコードはスキップされなくなりました。

印刷ジョブの終了時の改行の抑制

通常、MultiValue で印刷をすると、データ行の印刷の最後に改行シーケンスが印刷されます。これは、通常は CR + LF です (ただし、SP-CONTROL で変更できます)。データ行の最後にこの改行シーケンスが印刷されない場合は、次の 3 つのシナリオが考えられます。

1. CHAR(255):"BINARY": シーケンスで指定された、行のバイナリ・データを出力する場合。

2. データ行の直後の行に改ページ文字がある場合。この場合、改行シーケンスが不要となるだけでなく、意図していなかった空白ページが作成されることもあります。

3. 印刷ジョブの最後。改行が印刷されるときにページがいっぱいであった場合も、空白ページが作成されることがあります。作成されるかどうかは、SP-SKIP 設定を使用した改ページの指定で、最後の改ページがどのように判断されるようになっているかによります。

印刷ジョブの最後に、従来どおりページが送られることがまれにあります。その場合、ジョブ終了時の改ページを正確に定義するように SP-SKIP でフォーム・キュー設定を修正する必要があります。

名前付き COMMON の一致チェック

2 つのプログラムに異なる数の変数を持つ同じ名前の COMMON 領域がある場合、2 番目のプログラムの実行時に <COMMON MISMATCH> エラーがスローされるようになりました。ただし、UNIDATA エミュレーションではエラーは発生しません。

名前付き COMMON の初期化

名前付き COMMON 変数は、エミュレーションまたは指定された $OPTIONS に従って初期化されるようになりました。 CLEAR COMMON /name/ により、名前付き COMMON のすべての変数がクリアされます。

任意のアカウントでの TANDEM の使用

マスタ制御ターミナルとして TANDEM を使用する場合、SYSPROG アカウント特権が不要になりました。既定では、任意の MV アカウントから、実行中のターミナルに対して TANDEM を使用できます。TANDEM マスタになる前に、クライアント・ターミナルは次のコマンドを使用してそのターミナル自体を有効にする必要があります。

TANDEM ON

このコマンドは、以下をサポートするように機能拡張されました。

TANDEM SYSPROG

こちらは TANDEM ON と似ていますが、SYSPROG セキュリティが施行されるようになりました。つまり、ターミナルを管理するマスタになる任意のターミナルは、SYSPROG アカウントから実行する必要があります。

Caché ユーザ名を使用するように MV ログインを変更

MV シェルの開始時に、OS ユーザではなく、Caché ユーザと同じ名前の Proc または Paragraph が検索されるようになりました。この変更により、@LOGNAME 値でなく @AUTHORIZATION 値が検索されることになります。この変更は、Windows ユーザには影響しません。UNIX® MV ユーザは、Username でなく OSUserName を使用している場合、ログイン proc の名前を変更する必要がある場合があります。

Zen コンポーネントへの USECOMMONDIRECTORY パラメータの追加

既定では、Zen クラスは生成された js および css ファイルをそれらが定義されているネームスペースに対応する CSP ディレクトリに書き込みます。これは、他のネームスペースにマップされるパッケージでは非常に不便なことです。そのため、この変更によって、既定の動作を変更できるようになりました。Zen コンポーネント・クラスでその USECOMMONDIRECTORY クラス・パラメータが 1 に設定されている場合、そのクラスに対して生成されたファイルはいずれも共通の /csp/broker ディレクトリ内に配置され、すべてのネームスペースで表示されます。

これは多少高度な機能であるため、いくつかの重要な注意事項があります。

• 同じクラス・パッケージ内のすべての Zen クラスは、USECOMMONDIRECTORY に対して同じ値を定義 (または継承) する必要があります。そうしないと、コンパイル時にアプリケーションのエラーが発生します。

• USECOMMONDIRECTORY を指定せずにコンパイルされていたクラスで USECOMMONDIRECTORY を有効にする場合、以前に生成された .js および .css ファイルはローカル CSP ディレクトリから削除する必要があります。そうしないと、それらのファイルが引き続き使用されてしまいます。

• このメカニズムは、パッケージがシステム全体でマップされることを想定しています。USECOMMONDIRECTORY を使用する、異なるネームスペースで同じ名前を持つ 2 つのパッケージ間で競合を回避するメカニズムはありません。その場合、この機能は使用しないでください。

UNIX® 上で生成される子プロセス・ファイル記述子の変更

UNIX® プラットフォーム上の $zf(-2, <path>) で開始される外部プログラムは、/dev/null にリダイレクトされるファイル記述子 0、1、および 2 で実行されるようになりました。以前のバージョンでは、これらの記述子はプログラムの開始前に閉じられていました。

AIX での $FNUMBER の解析の修正

以前のバージョンでは、AIX プラットフォームで、$FNUMBER(n,format) に渡される不正なフォーマット文字列が検出されないことがありました。検出されない不正なフォーマット文字列は、"P" (かっこ) と任意の "+-TL" (+、-、先頭、または末尾) とを組み合わせたものです。これらについては、<SYNTAX> エラーが生成されるようになりました。

Symantec Backup Exec

Symantec Backup Exec ソリューション は磁気テープ・デバイス用の追加のドライバ・ファイル (tpfilter.sys) をインストールすると考えられます。このドライバの特質により、Caché から磁気テープへのバックアップが不可能になります (HP Ultrium 920 SAS ストリーマで最初に確認)。

この問題を示す症状は以下のとおりです。

• Windows デバイス・マネージャのデバイス・プロパティから [テープ シンボリック名] タブが消滅している。

• “\\.\Tape0” デバイスが使用不可能になり、'o 47:("auv":0:2048)' がハングしたまま復帰しない。

効果的な解決策は (Backup Exec のアンインストールによる) ドライバのアンインストールのみです。