9.1 組み込み関数の規則

ロングネーム

LANSAオブジェクトを参照する場合、大多数の既存の組み込み関数は、オブジェクトIDにのみに対応しています。ロングネームをサポートする組み込み関数はそれぞれ明示されています。

BIF の引数と戻り値のタイプ

入力引数または戻り値のタイプはA、N、L、U、w またはXが使用できます。

Date、Datetime、およびBLOBなどのその他のフィールド・タイプはすべて独自タイプに分類されます。したがって、'A'または'N'タイプの引数/戻り値に有効ではありません。これらのフィールド・タイプを使用するには、組み込みファンクションを使って適切なクラスに強制型変換する必要があります。組み込みファンクションに関する詳細については、「組み込みファンクション」を参照してください。

ユーザーが定義した組み込み関数のフィールド・タイプはすべてのRDMLXフィールド・タイプと正確に一致させる必要があります。そのため、ユーザーが定義した組み込み関数の宣言でStringが使用される場合、呼び出し時に使用できるものはStringのみです。Alpaフィールドは使用できません。しかし、Alphaで引数として宣言された場合は、Stringフィールドを利用できます。これは、下位互換性をサポートするための例外です。ユーザーが定義した組み込み関数は、X、U またはwタイプで引数または戻り値を宣言できません。 

'X' は特別な引数/戻り値のタイプで、すべてのフィールド・タイプを使用できます。 

フィールドとリテラル 

引数の長さに50を超える値の指定が許されるのは、フィールドの場合だけです。リテラル値は最大長が50に制限されます。 

RDMLX の引数や戻り値に対するFFC警告(FFC エラーではない) 

最大長が256桁のA、u、w またはX(すべて)の引数または戻り値に、それよりも長いフィールドが渡された場合、エラーではなくFFC警告が発生します(BIF は256バイト長を超えるフィールドに対処することができません)。 

最大長が30桁で最大小数点以下桁数が9桁のNタイプの引数または戻り値に、それよりも長いフィールドが渡された場合、エラーではなくFFC警告が発生します(BIFは30,9を超えるフィールドに対処することができません)。 

RDMLX の無制限長/ 無制限小数点以下桁数 

BIFの引数や戻り値の中には、新しい最大長の値である2147483647、つまり無制限を定義できるものがあります。この場合、フィールド長の最大/最小をチェックする必要はありません。 

NまたはXの引数や戻り値の中には、新しい小数点以下桁数の最大値である32767、つまり無制限を定義できるものがあります。この場合、小数点以下桁数の最大/最小をチェックする必要はありません。 

Integer フィールド・タイプ 

Integerフィールド・タイプは、長さではなくバイト数でサイズを指定します。小数部はなく正確です。 

次のテーブルにはIntegerで考えられる各バイト長の暗黙の長さが示されています。暗黙の長さは、SignedまたはPackedフィールドの実際の長さに相当します。

Integerタイプのフィールドは、以下の条件下でのみ、数値の引数または数値の戻り値として使用することができます。

• 引数または戻り値の最小小数点以下桁数が0であること
• 引数または戻り値の最小長がIntegerフィールドの暗黙の長さ以下であること。例えば、引数の最小長が4の場合、1バイトのIntegerを使用することはできません(暗黙の長さが3しかないため)。
• 引数または戻り値の最大長が2147483647、または引数または戻り値の最大長がIntegerフィールドの暗黙の長さ以上であること。例えば、引数の最大長が4の場合、2、4、8バイトのIntegerを使用することはできません(暗黙の長さが5以上のため)。

タイプFloatのフィールド

Floatフィールド・タイプは、長さではなくバイト数でサイズを指定します。小数部を仮定することはできますが固定長ではありません。また、特定の桁数に対して正確です。 
次のテーブルはFloatで考えられる各バイト長の正確な長さの一覧です。正確な長さはSignedまたはPackedフィールドの実際の長さに相当すると考えることができます。考えられる実行時の小数点以下桁数もテーブルに示されています。

Floatタイプのフィールドは、実行時に0から15桁の間のどこにでも小数点を持つことができるため、一般的にBIFの数値引数には不適切であると考えられています。実際の小数点位置を予測することが不可能なためです。数値引数にFloatタイプのフィールドが使用された場合、引数の最大長が2147483647でなければ、FFC警告が発生します。

ただし、Floatタイプのフィールドは以下の条件下では、数値の戻り値に適します。

• 最大長が2147483647に定義された場合、どのようなサイズも受け入れられます。また戻り値の最大小数点以下桁数が1以上の場合、どのような小数点以下桁数も正常であり受け入れられます。
• 戻り値の最小長および最小小数点以下桁数がFloatフィールドの正確な長さ以下であること。例えば、引数の最小長が10の場合、4バイトのFloatを使用することはできません(6桁までしか正確ではないため)。また、例えば、引数の最小小数点以下桁数が7の場合、4バイトのFloatを使用することはできません(小数点以下6桁までしか正確ではないため)。これは、Float長が上記表のように調整されることを前提として、通常の数値チェックの一部として実行します。最小長が10桁の場合、使用される数値のタイプにかかわらず6桁の数値はエラーとなります。同様に、最小小数点以下桁数が7桁の場合、最小長は7桁以上にする必要があります。したがって、この場合も6桁の数値はエラーになります。
• 現在、LANSAに搭載されているすべてのBIFにおいて、最大の最小小数点以下桁数は1です。では、なぜ最小小数点以下桁数に制限があるのでしょうか。さらに大きな最小小数点以下桁数が必要なユーザー(または新しいLANSA BIF)により、BIFが定義される場合があるからです。

英数字の引数と戻り値の規則

英数字の引数または戻り値が必要な場合、BIF の引数と戻り値のタイプ に加えて以下の規則が適用されます。

• StringまたはCharタイプのフィールドの長さが、引数または戻り値に指定された長さの範囲内であれば、そのフィールドを使用することができます。注：最大長が 2147483647 の場合、どのような長さでも使用することができます。
• NChar または Nvarchar のフィールド・タイプは、asNativeString組み込みファンクションを使用して英数字の引数に強制型変換し、かつ上記と同様に長さを制限する必要があります。この組み込みファンクションについては AsNativeString を参照してください。
• 他のすべてのRDMLXフィールド・タイプは、asString組み込みファンクションを使用して英数字の引数に強制型変換し、かつ上記と同様に長さを制限する必要があります。組み込みファンクションの使用に関する詳細については、「組み込みファンクション」を参照してください。
• BLOBおよびCLOBタイプのフィールドに実際に含まれているのは、ファイル名(最大長は256)です。ファイル名にアクセスするには#Myblob.Value構文のほかに #Myblob.asString も使用することができます(BLOBまたはCLOBファイル名の内容をＢＩＦの引数や戻り値として有効とするかどうかについては開発者が決定します)。
• Date(長さは常に10桁)、Time(長さは常に8桁)、およびDateTime(長さは19から29桁の間)は、asStringと指定通りの長さチェックが必要です(Date、Time、またはDateTimeの内容をＢＩＦの引数や戻り値として有効とするかどうかについては開発者が決定します)。

Unicode の引数と戻り値の規則

XおよびUタイプの引数および戻り値がUnicodeをサポートしています。

Unicodeの引数および戻り値の規則は英数字のものと同じです。例外は以下のとおりです。

• RDML オブジェクトでは、Unicodeの引数または戻り値は、英数字の引数または戻り値と全く同じように扱われます。
• RDMLX オブジェクトでは、NChar およびNvarcharタイプのフィールドを直接かつデータ損失なく使用できます。
• Unicode の引数をUnicodeフィールドで使用する場合、Unicodeの戻り値にはUnicodeフィールドを使用しなければなりません。これにより、Unicodeがネイティブに変換される時の暗黙的なデータ損失を防ぎます。ただし、逆のケースは違います。Unicodeの戻り値をネイティブ・フィールドで使用する場合、Unicodeの戻り値はUnicodeフィールドまたはネイティブ・フィールドのいずれも使用できます。暗示的なデータ損失がないためです。

リストの引数と戻り値の規則

FFCは作業リストの合計バイト長を検査しません。BIFが特定の合計バイト長を必要とする場合、合計バイト長が正しいかどうかを確認する必要があります。 

すべての多言語組み込み関数 

DBCS SQL Server以外のデータベース・サーバーでは、DBCSデータが壊れる可能性があります。DBCS SQL Serverでは、その他すべての言語のテキストが壊れる可能性があります。データの破損を確実に防ぐには、データベース・サーバーの文字セットと互換性があるテキストのみ変更してください。 

Visual LANSAに統合されている開発環境では、さまざまな方法でデータベースIOが実行されるため、データの破損を防ぐことができます。