データ型

DDL データ型のテーブル

MAXLEN およびスペースの使用

MAXLEN 値を過度に大きくして Caché SQL に影響を与えないようにしてください。%Library.StringOpens in a new tab データ型を指定する場合は、指定する MAXLEN 値を実際のデータ・サイズに厳密に一致させる必要はありません。フィールド値が "ABC" の場合、ディスク上、グローバル・バッファ内、およびプライベート・プロセス・メモリ内でそこまで多くのスペースを使用するのは、Caché のみとなります。フィールドが MAXLEN=1000 で定義されている場合であっても、プライベート・プロセス・メモリのスペースがそこまで多くフィールドに割り当てられることはありません。Caché は、宣言された長さにかかわらず、フィールド値の実際のサイズでしかメモリを割り当てません。

ODBC アプリケーションは、MAXLEN 値が過度に大きいことによって影響を受ける可能性があります。ODBC アプリケーションは、サーバからメタデータに基づいて、必要なフィールド・サイズを決定しようとします。そのため、このアプリケーションは、実際に必要な量よりも多くのバッファ・スペースを割り当てる可能性があります。このため、Caché では、システム全体の既定の ODBC VARCHAR の最大長を 4096 に設定します。この既定値は構成可能です。現在の設定を確認するには、$SYSTEM.SQL.CurrentSettings()Opens in a new tab を呼び出します。Caché ODBC ドライバは、TCP バッファからデータを取得し、それをアプリケーションのバッファに変換します。そのため、MAXLEN のサイズが ODBC クライアントに影響することはありません。

MAXLEN 値を過度に大きくして JDBC アプリケーションに影響を与えないようにしてください。Java および .Net には、アプリケーションが割り当てるバッファはありません。クライアントは、ネイティブ・タイプとしてデータを保持するために必要な量を割り当てられるだけです。

精度とスコープ

NUMERIC(6,2) などの数値データ型は、2 つの整数値 (p,s) による精度とスコープを持ちます。これらは Caché %Library クラスのデータ型にマップされています (“DDL データ型マッピングの理解” を参照)。SQL データ型で指定された場合、Windows システム上では以下のことが当てはまります (他のシステムでは最大値が異なる場合があります)。

• 精度 ： 0 ～ 19+s の整数。この値によって、最大と最小の許容値が決定されます。これは一般に数値の合計桁数ですが、その正確な値は、%Library クラス・データ型のマッピングによって決定されます。最大整数値は 9223372036854775807 です。 精度が 19+s より大きい場合は、既定で 19+s になります。

• スコープ ： 許容される最大小数桁数を指定する整数。正の整数、ゼロ、または負の整数を指定できます。s が p 以上の場合は、小数値のみが許可されて、実際の p 値は無視されます。許容される最大スコープは 18 であり、これは .999999999999999999 に相当します。 スコープが 18 より大きい場合は、既定で 18 になります。

以下の例は、精度とスコープのさまざまな組み合わせの最大値を示します。

  FOR i=0:1:6 {
      WRITE "Max for (",i,",2)=",$$maxval^%apiSQL(i,2),!}

SQL システム・データ型マッピング

上記のテーブルで DDL および Caché データ型の式に関して示した構文は、SQL.SystemDataTypes 用に構成された既定のマッピングです。システムで用意したデータ型とユーザ・データ型で個別のマッピング・テーブルが用意されています。

現在のデータ型のマッピングを表示および変更するには、管理ポータルに進み、システム, 構成, システム定義DDLマッピング を選択します。

DDL データ型マッピングの理解

DDL から Caché にデータ型をマッピングするとき、通常のパラメータと関数パラメータに以下の規則が適用されます。

• 通常のパラメータ — これらは、DDL データ型と、%# という形式の Caché データ型で認識されます。以下はその例です。

       VARCHAR(%1)
  

  

  これは、以下をマップします。

       %String(MAXLEN=%1)
  

  

  したがって、以下の DDL データ型は、以下のとおりです。

       VARCHAR(10)
  

  

  これは、以下をマップします。

       %String(MAXLEN=10)
  

  

• 関数パラメータ — これは DDL データ型のパラメータが、Caché データ型に入力される前にいくつかの変換を行う必要があるときに使用されます。この例は、DDL データ型の数値精度やスケール・パラメータの、Caché データ型の MAXVAL、MINVAL、および SCALE パラメータへの変換です。以下はその例です。

       DECIMAL(%1,%2)
  

  

  これは、以下をマップします。

       %Numeric(MAXVAL=<|'$$maxval^%apiSQL(%1,%2)'|>,
                MINVAL=<|'$$minval^%apiSQL(%1,%2)'|>,
                SCALE=%2)
  

  

  DDL データ型の DECIMAL は Precision (%1) と Scale (%2) パラメータを持ちますが、Caché データ型の %Numeric は精度パラメータを持ちません。そのため、DECIMAL を %Numeric に変換するには、Precision パラメータが適切な %Numeric パラメータに変換される必要があります。それには、Caché 関数の format、maxval、および minval を、DECIMAL のパラメータに対して適用します。特別な <|'xxx'|> 構文 (上記に示す) は、DDL プロセッサにパラメータ置換を指示し、指定された値で関数を呼び出します。次に、<|'xxx'|> 式は、関数の呼び出しから返された値で置き換えられます。

  以下は実際に数値を使用した例で、精度 4 桁とスケール 2 が指定された DECIMAL データ型です。

       DECIMAL(4,2)
  

  

  これは以下をマップします。

       %Numeric(MAXVAL=<|'$$maxval^%apiSQL(4,2)'|>,
                MINVAL=<|'$$minval^%apiSQL(4,2)'|>,
                SCALE=2)
  

  

  また、以下を評価します。

       %Numeric(MAXVAL=99.99,MINVAL=-99.99,SCALE=2)
  

  

  数値のフォーマットに関する詳細は、"Caché ObjectScript リファレンス" の "$FNUMBER" コマンドを参照してください。maxval および minval 関数の詳細は、次のトピックを参照してください。

データ型の優先順位

操作によって返すことができる値が複数存在し、それらの値のデータ型が複数にわたる場合は、Caché により、返り値に優先順位の最も高いデータ型が割り当てられます。例えば、NUMERIC データ型には INTEGER データ型として考えられる値がすべて含まれますが、INTEGER データ型には NUMERIC データ型として考えられる値がすべて含まれるわけではありません。したがって、NUMERIC のほうが優先順位が上であり、INTEGER よりも包括的です。

例えば、CASE 文で返すことができる結果値のデータ型として INTEGER と NUMERIC がある場合、結果値がこのどちらであっても、実際に返される結果値のデータ型は必ず NUMERIC になります。

データ型の優先順位は、高いもの (最も包括的) から低いものの順に以下のとおりです。

LONGVARBINARY
LONGVARCHAR
VARBINARY
VARCHAR
GUID
TIMESTAMP
DOUBLE
NUMERIC
BIGINT
INTEGER
DATE
TIME
SMALLINT
TINYINT
BIT

正規化および検証

%Library.DataTypeOpens in a new tab スーパークラスには、特定のデータ型のためのクラスが含まれています。これらのデータ型クラスには、入力値をデータ型形式に正規化するための Normalize() メソッド、入力値がそのデータ型に有効かどうかを判断するための IsValid() メソッド、および LogicalToDisplay() や DisplayToLogical() などのさまざまなモード変換メソッドが用意されています。

以下の例では、%TimeStamp データ型のための Normalize()Opens in a new tab メソッドを示しています。

  SET indate=63445
  SET tsdate=##class(%Library.TimeStamp).Normalize(indate)
  WRITE "%TimeStamp date: ",tsdate

  SET indate="2014-2-2"
  SET tsdate=##class(%Library.TimeStamp).Normalize(indate)
  WRITE "%TimeStamp date: ",tsdate

以下の例では、%TimeStamp データ型のための IsValid()Opens in a new tab メソッドを示しています。

  SET datestr="July 4, 2014"
  SET stat=##class(%Library.TimeStamp).IsValid(datestr)
    IF stat=1 {WRITE datestr," is a valid %TimeStamp",! }
    ELSE {WRITE datestr," is not a valid %TimeStamp",!}

  SET leapdate="2004-02-29 00:00:00"
  SET noleap="2005-02-29 00:00:00"
  SET stat=##class(%Library.TimeStamp).IsValid(leapdate)
    IF stat=1 {WRITE leapdate," is a valid %TimeStamp",! }
    ELSE {WRITE leapdate," is not a valid %TimeStamp",!}
  SET stat=##class(%Library.TimeStamp).IsValid(noleap)
    IF stat=1 {WRITE noleap," is a valid %TimeStamp",! }
    ELSE {WRITE noleap," is not a valid %TimeStamp",!}

日付、時刻、およびタイムスタンプのデータ型

ユーザは日付データ型、時刻データ型、タイムスタンプ・データ型を定義し、それらを Caché SQL の標準の日付関数および時刻関数を使用して相互変換できます。例えば、CURRENT_DATE や CURRENT_TIMESTAMP をデータ型で定義されたフィールドへの入力として使用したり、DATEADD、DATEDIFF、ATENAME、または DATEPART を使用して、このデータ型で保存された日付値を操作したりできます。

データ型クラスの %Library.DateOpens in a new tab、%Library.TimeOpens in a new tab、%Library.TimeStampOpens in a new tab、%MV.DateOpens in a new tab、%Library.FilemanDateOpens in a new tab、および %Library.FilemanTimeStampOpens in a new tab は、SqlCategory に関して次のように処理されます。

1. %Library.DateOpens in a new tab クラスおよび +$HOROLOG ($HOROLOG の日付部分) の論理値を持つユーザ定義のデータ型クラスは、DATE を SqlCategory として使用する必要があります。

2. %Library.TimeOpens in a new tab クラスおよび $PIECE($HOROLOG,”,”,2) ($HOROLOG の時刻部分) の論理値を持つユーザ定義のデータ型クラスは、DATE を SqlCategory として使用する必要があります。TIME は秒の小数部をサポートするので、このデータ型はユーザが指定した精度の桁数に合わせて HH:MI:SS.FF にも使用できます。秒の小数部をサポートするには、Precision パラメータを設定します。0 の値を設定すると、値は最も近い秒まで丸められます。"" (既定) の値を設定すると、データ値に指定された精度が保持されます。

   %Time データ型を使用するフィールドは、以下のように精度と小数桁数を xDBC に報告します。precision 引数が指定されていない場合、または 0 や "" として指定されている場合、xDBC は precision=8 および scale=0 を設定します。秒の小数部は切り捨てられます。precision 引数が設定されている場合、xDBC は precision=8+precision および scale=precision を設定します。

3. %Library.TimeStampOpens in a new tab クラスおよび YYYY-MM-DD HH:MI:SS.FF の論理値を持つユーザ定義のデータ型クラスは、TIMESTAMP を SqlCategory として使用する必要があります。%Library.TimeStampOpens in a new tab の最大精度はシステム・プラットフォームの精度から導き出されます。

4. %Library.DateTimeOpens in a new tab は %Library.TimeStampOpens in a new tab のサブクラスです。これは、DATEFORMAT という名前の型パラメータを定義します。また、TSQL アプリケーションで習慣的に使用されている不正確な日時入力に対処するよう、DisplayToLogical() および OdbcToLogical() メソッドをオーバーライドします。

5. %MV.DateOpens in a new tab クラスまたは $HOROLOG-46385 の論理日付値を持つユーザ定義のデータ型クラスは、MVDATE を SqlCategory として使用する必要があります。

6. %Library.FilemanDateOpens in a new tab クラスまたは CYYMMDD の論理日付値を持つユーザ定義のデータ型クラスは、FMDATE を SqlCategory として使用する必要があります。

7. %Library.FilemanTimeStampOpens in a new tab クラスまたは CYYMMDD.HHMMSS の論理日付値を持つユーザ定義のデータ型クラスは、FMTIMESTAMP を SqlCategory として使用する必要があります。

8. 上記の論理値のいずれにも当てはまらないユーザ定義の日付データ型には、データ型の SqlCategory を DATE として定義し、データ型クラスに LogicalToDate() メソッドを指定して、ユーザ定義の論理日付値を %Library.DateOpens in a new tab 論理値に変換し、DateToLogical() メソッドを指定して %Library.DateOpens in a new tab 論理値をユーザ定義の論理日付値に変換する必要があります。

9. 上記の論理値のいずれにも当てはまらないユーザ定義の時刻データ型には、データ型の SqlCategory を TIME として定義し、データ型クラスに LogicalToTime() メソッドを指定して、ユーザ定義の論理時刻値を %Library.TimeOpens in a new tab 論理値に変換し、TimeToLogical() メソッドを指定して %Library.TimeOpens in a new tab 論理値をユーザ定義の論理時刻値に変換する必要があります。

10. 上記の論理値のいずれにも当てはまらないユーザ定義のタイムスタンプ・データ型には、データ型の SqlCategory を TIMESTAMP として定義し、データ型クラスに LogicalToTimeStamp() メソッドを指定して、ユーザ定義の論理タイムスタンプ値を %Library.TimeStampOpens in a new tab 論理値に変換し、TimeStampToLogical() メソッドを指定して %Library.TimeStampOpens in a new tab 論理値をユーザ定義の論理タイムスタンプ値に変換する必要があります。

Caché では、FMTIMESTAMP カテゴリ値と DATE カテゴリ値を比較する場合に、DATE と比較する前に FMTIMESTAMP 値から時間を削除することはなくなりました。この動作は、TIMESTAMP と DATE の値の比較、および TIMESTAMP と MVDATE の値の比較に対する動作と同じになりました。これは、他の SQL ベンダによるタイムスタンプと日付の比較方法とも互換性があります。つまり、FMTIMESTAMP 320110202.12 と DATE 62124 の比較は、SQL等値 (=) 演算子を使用した比較では等しくなります。アプリケーションでは、FMTIMESTAMP 値を DATE または FMDATE 値に変換して値の日付部分のみを比較する必要があります。

1840 年 12 月 31 日より前の日付

日付は一般的に、DATE データ型で表されます。このデータ型は、$HOROLOG 形式で日付を格納し、任意の開始日 1840 年 12 月 31 日以降の日数を正の整数値としてカウントします。

既定では、日付は正の整数値でのみ表すことができます (MINVAL=0)。ただし、MINIVAL 型パラメータを変更することで、1840 年 12 月 31 日より前の日付の格納を可能にできます。MINIVAL を負の数値に設定すると、1840 年 12 月 31 日より前の日付を負の整数値として格納できます。使用可能な最も前の MINIVAL 値は -672045 です。これは西暦 1 年 (CE) 1 月 1 日に対応します。DATE データ型で BCE (紀元前) の日付を表すことはできません。

Note:

これらの日付のカウントでは、グレゴリオ暦の導入 (1582 年 10 月に制定、ただし英国およびその植民地で採用されたのは 1752 年) による日付の変更が考慮されないことに注意してください。

ロケールの最小の日付は、以下のように再定義できます。

  SET oldMinDate = ##class(%SYS.NLS.Format).GetFormatItem("DATEMINIMUM")
  IF oldMinDate=0 {
    DO ##class(%SYS.NLS.Format).SetFormatItem("DATEMINIMUM",-672045)
    SET newMinDate = ##class(%SYS.NLS.Format).GetFormatItem("DATEMINIMUM")
    WRITE "Changed earliest date to ",newMinDate
    }
  ELSE { WRITE "Earliest date was already reset to ",oldMinDate}

上記の例では、ロケールの MINIVAL を、使用可能な最も早い日付 (1/1/01) に設定します。

Note:

Caché は、負の論理 DATE 値 (MINVAL<0 の %Library.Date 値) によるユリウス日の使用をサポートしていません。このため、このような MINVAL<0 値には、TO_CHAR 関数で返されるユリウス日付形式との互換性がありません。

長い文字列

Caché は長い文字列をサポートしています。長い文字列とは、32,767 文字 (64 KB) を超え、最大長が 3,641,144 文字までの文字列のことをいいます。一般に、このような文字列には %Stream.GlobalCharacterOpens in a new tab データ型のいずれかを割り当てる必要があります。(2011.1 より前のバージョンでは、これらに CStream%String (または %Library.GlobalCharacterStreamOpens in a new tab) データ型が割り当てられていました。この古いデータ型も引き続き完全にサポートされます。)

長い文字列のサポートが既定で有効になります。Caché インスタンスで長い文字列のサポートを無効または有効にできます。無効にした場合は、管理ポータルまたは ObjectScript の Config.MiscellaneousOpens in a new tab クラスの EnableLongStringsOpens in a new tab プロパティを使用して長い文字列を有効にできます。管理ポータルで、システム, 構成, メモリと開始設定 を選択します。システム全体で長い文字列のサポートを可能にするには、[長い文字列を有効にする] チェック・ボックスにチェックを付けます。続いて、[保存] ボタンをクリックします。長い文字列を有効化した後で、そのシステムで呼び出されたプロセスはすべて、長い文字列をサポートします。詳細は、"Caché ObjectScript の使用法" の “データ型とデータ値” の章の "長い文字列" を参照してください。

長い文字列を有効にすると、%Library.StringOpens in a new tab データ型に 16,374 を超える Unicode 文字 (または 32K の 8 ビット文字) の MAXLEN を割り当てることができます。そのような長い文字列の処理方法は、使用する xDBC プロトコルに依存します。

• プロトコル 46 ： ODBC または JDBC から、MAXLEN が 16,374 文字を超える %Library.StringOpens in a new tab データにアクセスすると、最初の 16,374 文字のみが返されます。1 つのフィールドで 16,374 文字より長いデータをサポートする必要がある場合には、ストリーム・データ型を使用してください。

• プロトコル 47 ： ODBC または JDBC 文字列長に制限はありません。

使用されるプロトコルは、Caché インスタンスと ODBC ドライバ機能の両方によりサポートされる最も高いプロトコルです。ホスト上とクライアント上の両方のすべての機能がプロトコル 47 をサポートしている場合、そのプロトコルが使用されます。いずれかの機能がプロトコル 46 のみをサポートしている場合は、その他の機能がプロトコル 47 をサポートしていても、プロトコル 46　が使用されます。実際に使用されたプロトコルは、Caché ODBC ログに記録されます。

既定では、Caché はシステム全体の ODBC VARCHAR の最大長を 4096 に設定します。この ODBC の最大長は構成可能です。

リスト構造

Caché は、リスト構造のデータ型 %List (データ型クラス %Library.List) をサポートしています。これは圧縮バイナリ形式であり、Caché SQL で対応するネイティブなデータ型にマップしません。その内部表現では、データ型 VARBINARY に対応しており、その MAXLEN の既定値は 32749 です。

このため、ダイナミック SQL では、WHERE 節での比較に %List データを使用できません。また、型 %List のプロパティ値を設定するときに、INSERT も UPDATE も使用できません。

ダイナミック SQL では、リスト構造化されたデータのデータ型が VARCHAR として返されます。

ODBC クライアントまたは JDBC クライアントを使用する場合には、LogicalToOdbc 変換を使用して、%List データが VARCHAR 文字列データに投影されます。リストは、各要素がコンマで区切られた文字列として投影されます。この型のデータは、WHERE 節、INSERT 文および UPDATE 文で使用できます。既定では、Caché はシステム全体の ODBC VARCHAR の最大長を 4096 に設定します。この ODBC の最大長は構成可能です。

データ型クラス %Library.ListOpens in a new tab の詳細は、"インターシステムズ・クラス・リファレンス" を参照してください。WHERE 節でのリストの使用に関する詳細は、"%INLIST" 述語および "FOR SOME %ELEMENT" 述語の説明を参照してください。リスト・データを文字列として処理する方法の詳細は、"%EXTERNAL" 関数を参照してください。

Caché SQL は、$LIST、$LISTBUILD、$LISTDATA、$LISTFIND、$LISTFROMSTRING、$LISTGET、$LISTLENGTH、$LISTTOSTRING の 8 つのリスト関数をサポートしています。ObjectScript は、この他に 3 つのリスト関数をサポートしています。$LISTVALID は式がリストであるかどうかを判断するときに、$LISTSAME は 2 つのリストを比較するときに、$LISTNEXT はリストから要素を順番に取得するときに使用します。

ストリーム・データ型

ストリーム・データ型は、Caché クラス・プロパティのデータ型 %Stream.GlobalCharacterOpens in a new tab (CLOB の場合) および %Stream.GlobalBinaryOpens in a new tab (BLOB の場合) に対応します。

ストリーム・データ型のフィールドは、ほとんどの SQL スカラ関数、集約関数、または単項関数で引数として使用できません。削除しようとすると、SQLCODE -37 エラー・コードが発行されます。例外であるいくつかの機能は、"Caché SQL の使用法" の "ストリーム・データ (BLOB と CLOB) の格納と使用" の章にリストされています。

ストリーム・データ型のフィールドは、ほとんどの SQL 述語条件で引数として使用できません。削除しようとすると、SQLCODE -313 エラー・コードが発行されます。ストリーム・フィールドを受け取る述語は、"Caché SQL の使用法" の "ストリーム・データ (BLOB と CLOB) の格納と使用" の章にリストされています。

インデックス内、および挿入/更新の実行時におけるストリーム・データ型の使用も制限されています。ストリームの制限の詳細は、"Caché SQL の使用法" の "ストリーム・データ (BLOB と CLOB) の格納と使用" の章を参照してください。

SERIAL データ型

SERIAL データ型のフィールドでは、ユーザ指定の正の整数値を使用できます。または、Caché では、連続する正の整数値をそのフィールドに割り当てることができます。

INSERT 操作では、SERIAL フィールドに以下のいずれかの値が指定されます。

• 値なし、0 (ゼロ)、または非数値 ： Caché では、指定された値が無視され、その代わり、このフィールドの現在のシリアル・カウンタ値が 1 ずつインクリメントされ、インクリメント後の整数がフィールドに挿入されます。

• 正の整数値 ： Caché では、フィールドにユーザ指定の値が挿入され、このフィールドのシリアル・カウンタ値がこの整数値に変更されます。

したがって、SERIAL フィールドには、一連のインクリメンタル整数値が含まれます。これらの値は、連続または一意とは限りません。例えば、SERIAL フィールドでは、1、2、3、17、18、25、25、26、27 といった一連の値が有効です。連続する整数は、Caché で生成されるか、またはユーザが指定します。連続しない整数はユーザが指定します。SERIAL フィールドの値を一意にする場合には、そのフィールドに UNIQUE 制約を適用する必要があります。

UPDATE 操作では、SERIAL フィールドに現在、値がない (NULL) 場合、またはその値が 0 の場合にのみ、そのフィールドを変更できます。それ以外の場合には、SQLCODE -105 エラーが生成されます。

Caché では、テーブル内の SERIAL フィールドの数には制約がありません。

ROWVERSION データ型

ROWVERSION データ型は、システムによって割り当てられる、1 で始まる一意の正の整数を含む読み取り専用フィールドを定義します。Caché は、挿入、更新、または %Save の各処理の一部として連続した整数を割り当てます。これらの値をユーザが変更することはできません。

Caché は、ネームスペース全体で 1 つの行バージョン・カウンタを維持します。ROWVERSION フィールドを含むネームスペース内のすべてのテーブルが、同じ行バージョン・カウンタを共有します。このように、ROWVERSION フィールドでは行レベルのバージョン・コントロールが可能なため、ユーザはネームスペース内の 1 つ以上のテーブルの行に対して行った変更の順序を決定できます。

テーブルごとに指定できる ROWVERSION データ型のフィールドは 1 つのみです。

一意キーや主キーに ROWVERSION フィールドを含めることはできません。ROWVERSION フィールドを IDKey インデックスの一部にすることはできません。

ROWVERSION の使用の詳細は、"Caché SQL の使用法" の “テーブルの定義” の章にある "RowVersion フィールド" セクションを参照してください。

Caché ODBC / JDBC で使用される DDL データ型

Caché ODBC は、DDL データ型のサブセットを使用して、このデータ型のサブセットに、その他のデータ型をマップします。これらのマッピングを元に戻すことはできません。例えば、CREATE TABLE mytable (f1 BINARY) 文は、mytable (f1 VARBINARY) として ODBC に投影される Caché クラスを作成します。Caché のリスト・データ型は、VARCHAR 文字列として ODBC に投影されます。

ODBC は、BIGINT、BIT、DATE、DOUBLE、GUID、INTEGER、LONGVARBINARY、LONGVARCHAR、NUMERIC、OREF、SMALLINT、TIME、TIMESTAMP、TINYINT、VARBINARY、VARCHAR のデータ型を公開します。既定では、Caché はシステム全体の ODBC VARCHAR の最大長を 4096 に設定します。この ODBC の最大長は構成可能です。

これらの ODBC/JDBC データ型の値の 1 つが Caché SQL にマップされると、以下の演算が実行されます。DOUBLE データが $DOUBLE を使用してキャストされます。NUMERIC データが $DECIMAL を使用してキャストされます。

GUID データ型は、Caché SQL の UNIQUEIDENTIFIER データ型に相当します。GUID / UNIQUEIDENTIFIER フィールドに有効な値を指定できないと、 #7212 一般エラーが生成されます。

クエリ・メタデータによってデータ型が返される

ダイナミック SQL を使用すると、クエリ内で指定した列のデータ型など、クエリに関するメタデータが返されます。

以下のダイナミック SQL の例は、Sample.Person および Sample.Employee 内の各列に対する ODBC データ型の列名および整数コードを返します。

  SET myquery="SELECT * FROM Sample.Person"
  SET rset = ##class(%SQL.Statement).%New()
  SET tStatus = rset.%Prepare(myquery)
    SET x=rset.%Metadata.columns.Count()
  WHILE x>0 {
    SET column=rset.%Metadata.columns.GetAt(x)
  WRITE !,x," ",column.colName," ",column.ODBCType
  SET x=x-1 }
  WRITE !,"end of columns"

  SET myquery="SELECT * FROM Sample.Employee"
  SET rset = ##class(%SQL.Statement).%New()
  SET tStatus = rset.%Prepare(myquery)
    SET x=rset.%Metadata.columns.Count()
  WHILE x>0 {
    SET column=rset.%Metadata.columns.GetAt(x)
  WRITE !,x," ",column.colName," ",column.ODBCType
  SET x=x-1 }
  WRITE !,"end of columns"

ODBC では Caché %List データ型値をコンマで区切られた値の文字列で表すので、リスト構造化されたデータ (Sample.Person 内の FavoriteColors 列など) は、データ型 12 (VARCHAR) を返します。

ストリーム・データ (Sample.Employee 内の Notes 列や Picture 列など) は、データ型 -1 (LONGVARCHAR) または -4 (LONGVARBINARY) を返します。

%Library.RowVersion は %Library.BigInt のサブクラスであるため、ROWVERSION フィールドはデータ型 -5 を返します。

詳細は、"Caché SQL の使用法" の "ダイナミック SQL" の章、および "インターシステムズ・クラス・リファレンス" の "%SQL.StatementOpens in a new tab" クラスを参照してください。

データ型の整数コード

クエリ・メタデータなどのコンテキストでは、列に定義されたデータ型が整数コードで返される場合があります。データ型を表すために使用される整数コードには、以下の 2 とおりがあります。

• %Library.ResultSet.GetColumnType()Opens in a new tab メソッドでは、クライアント・データ型のコードが返されます。これらの値は、"インターシステムズ・クラス・リファレンス" の "%Library.ResultSetOpens in a new tab" クラスに示されています。

• xDBC データ型コード (SQLType) は ODBC と JDBC で使用されます。前述の例で示すように、これらは %SQL.Statement.%Metadata.columns.GetAt() メソッドで返されます。JDBC のコードと ODBC のコードはほぼ同じですが、日付と時刻のデータ型の表現が異なります。これらの ODBC および JDBC の値は以下のとおりです。

  ODBC	JDBC	データ型
  -11	-11	GUID
  -7	-7	BIT
  -6	-6	TINYINT
  -5	-5	BIGINT
  -4	-4	LONGVARBINARY
  -3	-3	VARBINARY
  -2	-2	BINARY
  -1	-1	LONGVARCHAR
  0	0	不明な型
  1	1	CHAR
  2	2	NUMERIC
  3	3	DECIMAL
  4	4	INTEGER
  5	5	SMALLINT
  6	6	FLOAT
  7	7	REAL
  8	8	DOUBLE
  9	91	DATE
  10	92	TIME
  11	93	TIMESTAMP
  12	12	VARCHAR

詳細は、"Caché SQL の使用法" の "ダイナミック SQL" の章を参照してください。

Caché は、中国語、ヘブライ語、日本語、韓国語のロケールなど、マルチバイトの文字セットを使用する ODBC アプリケーション向けに Unicode SQL タイプもサポートします。

この機能を有効にする際、"Caché ODBC の使用法" の “コントロール・パネルを使用した DSN の作成” を参照してください。

DDL マッピングが見つからない場合のデータ型の処理

[UserDataTypes] テーブルの DDL データ型列にないデータ型が DDL で検出されると、次に [SystemDataTypes] テーブルが調べられます。どちらのテーブルにもデータ型マッピングがない場合は、そのデータ型は変換されず、DDL で指定されているクラス定義に直接渡されます。

例えば、以下のフィールド定義が DDL 文にあるとします。

     CREATE TABLE TestTable (
          Field1 %String,
          Field2 %String(MAXLEN=45)
          )

上記の定義では、%String、%String(MAXLEN=%1)、または %String(MAXLEN=45) のマッピングが、[UserDataTypes] と [SystemDataTypes] に見つからない場合、%String と %String(MAXLEN=45) 型が適切なクラス定義に直接渡されます。

CAST および CONVERT での VARCHAR の処理

前述のテーブルに示すように、(サイズが指定されていない) VARCHAR データ型は MAXLEN が 1 の文字にマップされます。ただし、値を VARCHAR に CAST または CONVERT する場合の既定のサイズのマッピングは 30 文字です。この既定サイズの 30 文字は、Caché 以外のソフトウェア要件との互換性を保持するために提供されています。