1.1.17 BLOB

BLOBは最大長が定義されていない可変長のバイナリー・フィールドです。

BLOBを使用する操作で最も一般的なものは、データベースへのファイルの保存やファイルの取得です。これでファイルの表示/編集などができるようになります。RDMLやRDMLXでは、BLOBフィールドはファイル名として処理されます。

次はJPGファイルをBLOBに保存する例です。

#MYBLOB := 'C:\temp\mypicture.jpg'
UPDATE FIELDS(#MYBLOB) IN_FILE(FILE1)

一般的な事柄については、「1.1.1 フィールド・タイプについて」を参照してください。

フィールド定義の規則

BLOBをリポジトリに定義するときの規則は以下のとおりです。

長さ

長さ指定は不可です。小数はありません。

有効な鍵盤シフト

ブランク

許容される属性

AB、ASQN、CS、FE、LC、ND、RA、RL、RLTB

注：LCとASQNは必ず定義する必要があります。削除はできません。

編集オプション

不可

デフォルト

*SQLNULL。デフォルトでASQNが有効になります。

フィールド定義の注意事項

  • BLOB の作業フィールド・タイプはありません。

使用規則

区画タイプ

RDMLX使用可能区画

ファイル

BLOBはRDMLXファイルでのみ使用することができます。BLOBフィールドは実フィールドとして使用することができます。BLOBはキー・フィールドとして使用してはいけません。

論理ビュー

BLOBはキー・フィールドとして使用できません。

仮想フィールド

適用不可

事前結合フィールド

適用不可

RDML コマンド

BLOBまたはCLOBフィールドを使用する場合、そのフィールドにはファイル名が含まれています。オブジェクトの実データではないので注意してください。RDMLやRDMLXでは、LANSA LOBフィールドはファイル名として処理されます。指名ファイルの読み書きによりBLOBまたはCLOBの実データそのものを処理するのは、データベースI/Oコマンドだけです。

組み込み関数

BLOBを組み込み関数で使用する場合、BLOBは独自のタイプに分類されるので数値または英数字の引数には無効です。

特殊値

*SQLNULL、*NAVAIL、*REMEMBERED_VALUE、*EMPTY

変換

BLOBはファイル・ポインターとして扱われます。数値や日付/時間フィールド・タイプへの変換はサポートされていません。詳細については、「フィールド・タイプ変換」を参照してください。

使用に関する注意事項

  • BLOB をキーの一部 (例：アクセス経路へのキーなど) にすることはできません。
  • BLOB データの表示または印刷はできません。
  • BLOB フィールドをリストに追加する場合、そのフィールドにはファイル名が含まれています。オブジェクトの実データではないので注意してください。
  • 条件に従って SQL の WHERE 句を生成する場合、このフィールド・タイプは *NULL または *SQLNULL としか比較することはできません。他との比較はすべて拒否されます。
  • BLOB タイプのフィールドのデフォルト・プロパティは、.Value ではなく、.FileName です。これは、このフィールドの「値」を変更することは、実際にはそのデフォルト・プロパティつまりファイル名プロパティが変更されるということを明確に示すためです。
  • BLOB フィールドは特定の制限に従います。
  • このフィールドを SELECT_SQL コマンド内で使用することはできません。
  • このフィールドを条件で使用することはできません。ただし、*NULL または *SQLNULL との比較は除きます。
  • 一部またはすべての DBMS への変更が記録されない場合があります。したがって、ロールバックの効果がない場合もあります。
  • LC 属性は常に有効です。無効にはできません。これは最初にファイル名に影響します。BLOBはバイナリー・タイプとして、あらゆるタイプのデータの使用を許します。したがって、ファイル内で小文字は無意味になります。
  • ASQN 属性は常に有効です。無効にはできません。
  • BLOB および CLOBデータ をデータベースから読み取ると、ディレクトリ構造内の LPTH= ディレクトリにファイルが自動的に作成されます (詳細については、「標準X_RUNパラメータ」を参照してください)。

プラットフォームについて

ヒントとテクニック

  • BLOBとCLOBフィールドを使用する場合に、それらのフィールドを他のフィールドとは別のファイルに配置してメイン・ファイルと同じキーを使用する設計をお勧めします。これによりプログラマは、BLOBやCLOBデータのアクセスに別々のI/O操作を行わなければならなくなり、このデータの無差別な使用によるデータベース・パフォーマンス上の影響を軽減することができます。またこれは最も移植性の高い設計で、BLOB以外またはCLOB以外のデータに常に迅速にアクセスできるようになります。
  • 読み取り時に作成される LOB ディレクトリが LANSA セッションの終了時に削除されないことがあります。特別なプロセス*LOBCLNUPを時々実行することで、LOBディレクトリ構造をクリーンアップできます。このプロセスは、他のユーザーが作成したファイルを削除する十分な権限を持つユーザーが実行する必要があります。例えば、IBM i では次のようなコマンドを使用します。 LANSA REQUEST(X_RUN) X_RUNADPRM('PROC=*LOBCLNUP')

次のトピックも参照してください。

1.1.18 CLOB

  • No labels