Caché 2008.1

長い文字列の制御

長い文字列の使用を有効化するオプションのある場所が変更されました。以前のバージョンでは、ホーム, 構成, 詳細設定 ページにありました。今回の Caché バージョンでは、ホーム, 構成, メモリと開始設定 に移動されています。

ジャーナル・ロールオーバーの変更

単純なジャーナル・ロールオーバーが、グローバルなジャーナル履歴のログ (^%SYS("JOURNAL","HISTORY")) に記録されなくなりました。ただし、cconsole.log にはこれまでと同様に記録されます。

ジャーナリングは必ずプライマリ・ディレクトリで始まります。プライマリ・ディレクトリとは現在のディレクトリを表し、セカンダリ・ディレクトリは代替のディレクトリを表します。この状態は、現在の (プライマリ) ディレクトリでジャーナリング・エラー (ディスクがいっぱいになるなど) が発生し、代替の (セカンダリ) ディレクトリにフェイルオーバーされるまで継続します。この時点で、セカンダリ・ディレクトリが現在のディレクトリとなり、プライマリ・ディレクトリが代替のディレクトリとなります。

Caché データベースの最大パス長の減少

このバージョン Caché では、インストール・ディレクトリにある Caché データベースおよびその他のアイテムの識別に使用できる最大パス長が、232 文字から 227 文字に減らされました。従来の上限に近いパス名がある場合は、パス名を調整して、新しい上限内に収まるようにする必要があります。Caché ファイル名の多用性に対応する目的で、パスのディレクトリ部分の長さは 195 文字以下にする必要があります。

ECP 構成のアップグレード後のクライアントからの SQL 権限の消失

データベース・サーバで SQL 権限を変換した後、mpriv グローバルは削除されます。このバージョン以降、Caché では権限がネームスペースではなく (ローカルの) SYS データベースに保存されるようになります。そのため、変換後はアプリケーション・サーバには権限が残りますが、保存されなくなります。権限は手動でクライアントに設定する必要があります。

Windows Vista

基盤となるプラットフォームの考慮事項により、Windows Vista 上の Caché は Raw Ethernet 上の DCP をサポートしません。同様に、Caché DDP および LAT はこのプラットフォームではサポートされません。

Mac

このバージョンの Caché では、Apple Mac OS X for PowerPC がサポートされなくなりました。

SPARC-64 上の Sun Solaris

今回のバージョンの Caché では、このプラットフォーム上の C++ および Light C++ バインディングがサポートされなくなりました。また、マルチスレッド・コールインもサポートされません。

SUSE Linux Enterprise for Itanium

今回のバージョンの Caché では、このプラットフォーム上の C++ および Light C++ バインディングがサポートされなくなりました。

DCP の制約

DCP の使用時には、以下に示す既知の制約があります。

• DCP では、^%RCHANGE ユーティリティを使用できません。NETWORK DATA UPDATE FAILED エラーが発生します。

• DCP を介して接続されたデータベースのマッピングは、システム管理ポータルに正しく表示されません。

DDP の制約

DDP の使用時には、以下に示す既知の制約があります。

• DDP では ^%GD ユーティリティを使用できません。<DIRECTORY> エラーが発生します。

• スタジオは DDP 上で動作しません。

• XML インポートおよびエクスポートは DDP 上で動作しません。

• DDP のグローバル長は 757 バイトを超えることはできません。

ODBC の制約

Caché 5.1 よりも前のバージョンの ODBC クライアントは、このバージョンとの互換性が完全ではありません。クライアント・システムのアップグレードを推奨します。

$REPLACE 関数の追加

今回のバージョンの Caché には、新しい文字列置換関数 $REPLACE が追加されました。$REPLACE(S1, S2, S3) は、文字列 S1 の中にある文字列 S2 をすべて見つけて、そのそれぞれを文字列 S3 に置換します。3 つの引数すべてが必須です。$TRANSLATE とは異なり、S2 および S3 は文字のリストとしてではなく完全な文字列として扱われます。

$ZDATETIMEH 検証の改善

このバージョンでは、ODBC および SQL の日付時刻検証が改善されました。各フィールド (日、月、時間、秒) の形式が不適切な場合、$ZDATETIMEH によりエラーが報告されるようになりました。例えば、月内の日には 2 桁のみが許可されるため、002 は有効な日として許可されなくなります。

非互換性 ：ON 節での 矢印構文

バージョン 2007.1 よりも前の Caché SQL では、ON 節で矢印構文を使用できました。これが可能であったのは、Caché が線形連鎖の外部結合 (1 つ以上のテーブルの 1 つのテーブルへの左外部結合) のみをサポートしていたためです。結果として、この非常に限定的なサポートの中では、矢印構文の組み合わせと =* 構文の使用、および ANSI 結合が混在する可能性がありました。

矢印構文は常に =* 構文と同等と定義されており、同じ基本メカニズムが使用されていました。そのため、ON 節ではサポートが不要になりました。

ON 節以外での矢印構文のサポート (WHERE 節、SELECT 節、GROUP BY、ORDER BY、HAVING) はこれまでと変わりません。

LEFT JOIN に関する制限

ON 節での LEFT JOIN に関する制限は、今回のリリースにも適用されます。特定のテーブルに影響するすべての条件に NULL 値を渡す比較が使用されており、そのテーブル自体が外部結合のターゲットとなっている場合、Caché は次のエラーを報告する可能性があります。

error 94: unsupported use of outer join

次に、これに該当するクエリの例を示します。

SELECT *
FROM Table1 
          LEFT JOIN Table2 ON Table1.k = Table2.k 
          LEFT JOIN Table3 ON coalesce(Table1.k,Table2.k) = Table3.k

LIKE への照合順序の適用

SQL LIKE 演算子の動作が、“=” や %STARTSWITH などの他の比較演算子と同様になりました。つまり、次のような式があるとします。

f LIKE <arg>

この式は次と同等に解釈されます。

Collation(f) LIKE Collation(<arg>)

Coll() は f の既定の照合です (他の演算子と異なり、この場合、<arg> の既定の照合は結果に影響しません)。

これは、既定の照合に %SQLSTRING、%SQLUPPER、%UPPER、および %SPACE が設定されたフィールドに適用されます。%MVR、%PLUS、および %MINUS には適用されません。また、%ALPHAUP および %STRING にも適用されません (これらは文字列から文字を削除できるためです)。

%SQLUPPER(50) などのトランケーションのある照合では、照合 (およびトランケーション) がフィールド値とパターンに適用されます。これは、実用面では、使用するパターンをトランケーション長よりも短くする必要があることを意味します。それ以外の場合は、認識困難な結果となる可能性があります。

COMMIT 動作の SQL 標準への準拠

アクティブな SAVEPOINT が複数あるときの COMMIT の動作が、SQL 標準に合致するように変更されました。純正な SQL アプリケーションの COMMIT アクションでは、入れ子になったトランザクションは、すべて直前の BEGIN TRANSACTION までコミットされます。実用的には、COS/SQL 混在のアプリケーションで COS コードによってトランザクションの入れ子レベルが追加作成される場合、SQL COMMIT によって、入れ子になったトランザクションはすべて SQL SAVEPOINT 文によって作成されていない最上位の $TLEVEL までコミットされます。

%TSQL.Manager.load() の置換

このリリースでは、%TSQL.ManagerOpens in a new tab の load() が非推奨になりました。TSQL ソース・ファイルのロードに使用する新しい推奨のメソッドは $SYSTEM.SQL.TSQL() です。この関数は、新しい %TSQL.ManagerOpens in a new tab.Import() メソッドと同様の引数を受け入れます。

TSQL プロシージャ定義の既定スキーマへのマッピング

$SYSTEM.SQL.TSQL() または ##class(%TSQL.Manager).Import() を使用して TSQL バッチを実行するときは、プロシージャ定義の保持用に作成されるクラスが、既定のスキーマにマッピングされたパッケージに収容されるようになりました。例えば、既定のスキーマが 'dbo' の場合、プロシージャ・クラスが作成されるパッケージは SQLNAME = 'dbo' で定義されたパッケージになります。

区切り識別子のサポート

今回のバージョンの Caché では、SQL ゲートウェイ接続設定にチェックボックスが追加され、ゲートウェイ上で送信される SQL 文で区切り識別子が使用できなくなりました。Sybase では区切り識別子がサポートされていないため、このオプションが追加されました。Sybase データベースに接続する場合、このオプションを選択しないと接続に失敗します。

ソース・コントロール・ドキュメントの互換性

今回のバージョンの Caché では、%Studio.SourceControl.InterfaceOpens in a new tab クラスの実装が変更されています。ただし、スタジオは、使用されるクラス・バージョンを検知して、それに応じて動作するようになっています。これにより、Caché のソース・コントロールを使用して、既存アプリケーションの変換をより細かく制御できるようになります。

バージョン間の互換性

このバージョンのスタジオは、5.2 よりも前のバージョンの Caché を実行するサーバへの接続を拒否します。これは、今回のリリースで導入されたセキュリティ機能によります。接続が拒否されると、開発者に “バージョンミスマッチ。 サーバはバージョン 5.2 およびそれ以降でなければなりません。 というメッセージが表示されます。”

ターミナルの識別情報

このバージョンでは、ターミナルが変更され、接続先のマシンと Caché インスタンスが表示されるようになっています。これらの項目は、ユーザ ID とパスワードを要求するプロンプトよりも前に表示されます。ターミナルの最初の出力がユーザ名を要求するプロンプトであることを前提にしているターミナル・スクリプトは、明示的にプロンプトを参照するように変更する必要があります。そうでないと、出力のタイミングによっては、一時的に失敗する可能性があります。

Telnet ターミナル・タイプのサポート

ターミナルで、“ターミナル・タイプ” Telnet オプションがサポートされるようになりました。Caché は、プロセスの起動時に、“ターミナル・タイプ” Telnet オプションのネゴシエーションを実行します。Telnet クライアントが同意しターミナル・タイプを送信すると、Caché は Windows の TERM 環境変数を定義します。この変数の値は、関数 $System.Util.GetEnviron("TERM") を使用して Caché から取得できます。

ZWELCOME

今回のバージョンの Caché には、ターミナル接続とユーザ･ログインの間に特定のコードを呼び出し実行するメカニズムが用意されています。

ターミナルの開始コードは、%SYS ネームスペースに ZWELCOME という名前のルーチンが存在するかどうかをチェックします。該当するルーチンが見つかると、ターミナルのログイン・シーケンスがある場合は、その直前にそのルーチンを呼び出します。このルーチンは、その名前が意図するように、カスタムな識別情報やようこそメッセージをユーザに表示する目的で使用されます。

%Library.String

LogicalToDisplay メソッドがこのバージョンで変更されました。内部形式の外部表現への変換に際して、文字列からすべての NULL ($CHAR(0)) 文字が削除されます。これは、LogicalToDisplay と DisplayToLogicalLogicalToDisplay が相互に可逆であるというこれまでの想定と矛盾します。

システムのデータ型に対して IsValidDT メソッドの生成を強制する機能の削除

前回のリリースでは、生成されるコードの量を減らし、クラス・コンパイラの速度を上げるために、システムのデータ型から IsValidDT メソッドを削除しました。その時点では、アプリケーションがそれ自体のコードから直接データ型の IsValidDT メソッドを呼び出す場合に備えて、フラグを 1 つ追加し、そのフラグを設定するとデータ型の IsValidDT メソッドを引き続き生成するようにしました。

このスイッチは、データ型の SQL プロジェクションに問題が発生する原因となるため、削除されました。

%XML.Document と %XML.Node

今回のバージョンの Caché には、XML ドキュメントをドキュメント・オブジェクト・モデル (DOM) として表現する %XML.DocumentOpens in a new tab クラスが導入されています。DOM は、次の 2 とおりの方法で作成できます。

• XML ドキュメントから作成 ： %XML.Reader の Openxxx メソッドを呼び出した後、%XML.Reader の Document プロパティにアクセスします。

• 新規インスタンスとして作成 ： CreateDocument メソッドを呼び出して、空のドキュメントをインスタンス化します。

ドキュメントは、%XML.DOM の多様な Writer および Tree メソッドを使用して、目的の場所に書き込むことができます。

%XML.NodeOpens in a new tab クラスは、DOM の構成要素へのアクセスに使用します。%XML.NodeOpens in a new tab は、DOM ツリー内の特定のノードの記述よりも、DOM の各ノード間のナビゲートに使用します。MoveToxxx メソッドは、DOM 内の移動に使用します。ノードのコンテンツの取得および変更には、%XML.NodeOpens in a new tab のプロパティおよびメソッドを使用します。

$SYSTEM.SQL の新しい関数

$SYSTEM.SQL クラスに、新しい関数が 2 つ追加されました。

• $SYSTEM.SQL.UserExists(UserId) ： <UserId> という名前のユーザが存在する場合は 1 を、存在しない場合は 0 を返します。

• $SYSTEM.SQL.RoleExists(RoleId) ： <RoleId> という名前のロールが存在する場合は 1 を、存在しない場合は 0 を返します。

MANAGEDEXTENT クラス・パラメータの追加

新しいデータ管理メカニズムがこのリリースで実装されました。そのため、データの管理に既定のストレージ・メカニズムである %Library.CacheStorageOpens in a new tab を使用するクラスの動作が、永続インスタンスに関しては、これまでと異なっています。

既定のストレージを利用する永続クラスで使用するグローバルは、新しいエクステント・マネージャで登録されるようになりました。このエクステント・マネージャへのインタフェースは、%ExtentMgr.UtilOpens in a new tab クラスで得られます。この登録プロセスはクラスのコンパイル時に実行されます。エラーまたは名前衝突は、そのすべてがエラーとして報告され、コンパイルは失敗します。衝突はユーザが解決する必要があります。名前衝突は、インデックスの名前を変更するか、またはストレージ場所を明示的に追加することで解決できます。

エクステント・メタデータは、クラスが削除された場合にのみ削除されます。スタジオを使用してエクステントを削除するには、スタジオの [ワークスペース] ウィンドウでクラス名を右クリックして、ネームスペースの既定として “e” フラグが設定されているメニューから [クラス '<classname>' の削除] を選択します。

使用可能なフラグおよび修飾子は、次のコマンドで参照できます。

Do $SYSTEM.OBJ.ShowFlags()
Do $SYSTEM.OBJ.ShowQualifiers()
Do $SYSTEM.OBJ.SetFlags()
Do $SYSTEM.OBJ.SetQualifiers()

クラスをリコンパイルするとエクステント・メタデータは更新されます。コンパイルに失敗した場合、メタデータは失敗時の状態のまま保持されます。

ユーザは、##class(%ExtentMgr.Util).DeleteExtent(<classname>) を使用することで、いつでもエクステント・メタデータを明示的に削除できます。

クラスにより使用されるグローバル参照を登録したくない場合は、MANAGEDEXTENT クラス・パラメータの値を 0 (ゼロ) に設定します。

ERROR #5564: Storage reference: '^This.App.Global used in 'User.ClassA.cls' 
is already registered for use by 'User.ClassB.cls'

%Zen.Report

%ZEN のレポートが変更されました。従来のバージョンにあった数値の問題が修正され、いくつかの機能が拡張されました。その概要は次のとおりです。

レポートで OnCreateResultSet コールバックを使用する際に、ユーザ定義のパラメータの配列を渡せるようにこのコールバックが改善されました。例えば、次のようにメソッド宣言をします。

ClassMethod RS1(ByRef pSC As %Status,  ByRef pParameters) As %ResultSet 

結果セットは次のとおりです。

<group name="city" 
       breakOnField="Home_City" 
       OnCreateResultSet="RS1"  
       parameter field="Home_City"/>

この場合、pParameters(1) には Home_City フィールドの現在値が入ります。この変更がある前は、ユーザが作成した結果セットにパラメータを渡すしくみがありませんでした。

このバージョンでは、クエリの入れ子に関する問題が修正されました。Zen レポートでは、外側に 1 つクエリを定義してそのクエリ内の列にグループ・レベルでブレークさせたり、グループ・レベルで追加クエリを取り入れることができます。後者の場合、入れ子になるクエリは一般的には次のように外側のクエリからパラメータを受け取ります。

<report sql="SELECT City FROM Table1 ORDER BY City">
<group name="City" 
       breakOnField="City" 
       sql="SELECT Employee FROM Table2 WHERE City=?">
<parameter field="City"/>

従来のバージョンでは、クエリの入れ子は正常に動作しないケースが多くありました。このバージョンでは、入れ子になるクエリは、外側のグループから新しいブレークの値に対して 1 回のみ実行されます。

また、クエリの入れ子の内部管理において、クエリ内のフィールドの参照を解決する際の一貫性が改善されました。基本ルールは次のとおりです。

1. グループごとに (外側のレポート・タグを含む)、そのグループの "レベル" の "クエリ・コンテキスト" を定義します。このレベルは、レポート定義の最上位からそのグループまでのネストの深さです。グループで新しいクエリが定義されない場合、親グループのクエリがそれ自身のクエリとして使用されます。

2. <group>、<parameter>、または　<attribute> ノード内のフィールドへの参照は、親ノードのクエリを参照することによって解決されます。

3. <element> および <aggregate> ノード内のフィールドへの参照は、そのノードと同じレベルのクエリを参照することによって解決されます。

次に例を示します。

<report sql="SELECT Name FROM Table1">
<element name="A" field="Name"/>

上記の場合、Name は、Table1 から得られます。別の例を示します。

<eport sql="SELECT Name FROM Table1">
<ttribute name="A" field="Name"/>

上記の場合、Name を解決できずにエラー・メッセージが生成されます。また別の例を示します。

<report sql="SELECT Name FROM Table1">
<group name="Name" sql="SELECT Name FROM Table2 WHERE...">
<element name="A" field="Name"/>

上記の場合、Name は Table2 に解決されます。さらに別の例を示します。

<report sql="SELECT Name FROM Table1">
<group name="Name" sql="SELECT Name FROM Table2 WHERE...">
<element name="A" field="Name"/>

上記の場合、Name は Table1 に解決されます。

クエリ内で存在しないフィールドを参照すると、そのフィールドの値は、“見つかりません” ではなく “” として返されるようになりました。

ReportDefinition で同じレベルの複数のグループ・ノードを定義できるようになりました。これらは “同位” グループと呼ばれ、Zen レポートのドキュメントで詳細が説明されています。同位グループに影響する特別なルールがいくつかあります。

• 列ブレーク・ロジックは最初の同位グループに対してのみ適用されます。グループが最初の同位グループでなければ、breakOnField も breakOnExpression も無視されます。

• 集約の計算は、最初の同位グループに入っているものに対してのみ行われます。

一般的に同位グループは、各同位グループで独自のクエリを定義する際に使用され、外側のクエリから共通の WHERE 節でブレーク・フィールドを参照します。同位グループで独自のクエリを定義しない場合も使用されます。 その場合、最初の同位グループはブレーク条件をテストしてそのレコードを出力し、後続の同位グループは同じ区切りフィールドで処理されます。

便宜上、レポート・エンジンでは指定されたグループ・レベルで変数 %node(level) を現在の数値と等しくなるように定義します。ReportDefinition の式内でこれを使用できます。以下はその例です。

<attribute expression="$G(%node(2))" name="num"/>