1.1.17 BLOB
BLOB is a variable-length binary field of undefined maximum length.
The most common operation with BLOBs are saving files into the database and retrieving them so they can be viewed/edited/etc. In RDML and RDMLX, BLOB fields are manipulated as filenames.
Following is an example of saving a JPG into a BLOB:
#MYBLOB := 'C:\temp\mypicture.jpg'
UPDATE FIELDS(#MYBLOB) IN_FILE(FILE1)
Please review the general 1.1.1 Field Type Considerations.
Field Definition Rules
Rules for defining a BLOB in the repository are:
|
Length |
Length cannot be specified. No decimals. |
|
Valid Keyboard Shift |
Blanks |
|
Allowed Attributes |
AB, ASQN, CS, FE, LC, ND, RA, RL, RLTB. Note: LC and ASQN must always be defined and cannot be removed. |
|
Edit Mask |
Not allowed. |
|
Default |
*SQLNULL. ASQN will be enabled by default. |
Field Definition Notes
- There is no working field type for BLOBs.
Usage Rules
|
Partition Type |
|
|
Files |
BLOBS may only be used in RDMLX Files. BLOB fields may be used as real fields. BLOBS must not be used as key fields. |
|
Logical Views |
BLOBS may not be used as key fields. |
|
Virtual Fields |
Not applicable. |
|
Predetermined Join Fields |
Not applicable. |
|
RDML Commands |
If a BLOB or CLOB field is used, keep in mind that the field contains a filename, not the actual data in the object. In RDML and RDMLX, LANSA LOB fields will be manipulated as filenames. It is only in database IO commands that the BLOB or CLOB actual data itself is handled by reading from or writing to the named file. |
|
Built-In Functions |
When used in Built-In Functions, BLOBs are classified as their own types and are not valid for numeric or alpha arguments. |
|
Special Values |
*SQLNULL, *NAVAIL, *REMEMBERED_VALUE, *EMPTY |
|
Conversion |
BLOBs are treated as file pointers and do not support conversion to a Numeric or Date/Time field type. Refer to Field Type Conversions. |
Usage Notes
- BLOBs cannot be part of any key (e.g. for Access Routes, etc.)
- You cannot display or print BLOB data.
- If a BLOB field is added to the list, keep in mind that the field contains a filename, not the actual data in the object.
- If an SQL WHERE clause will/may be generated by a condition, these field types may only be compared to *NULL or *SQLNULL; any other comparison will be rejected.
- Rather than the default property .Value, fields of type BLOB have a default property called .FileName to clearly indicate that changing the "value" of the field is actually changing its default property which is a file name property.
- BLOB fields are subject to certain restrictions:
- They cannot be used in SELECT_SQL commands.
- They cannot be used in a condition; the exception is comparison against *NULL, or *SQLNULL.
- Changes may not be logged (and therefore rollback may have no effect) on some or all DBMSs.
- The attribute LC is always enabled, and cannot be disabled. This will affect filenames initially. BLOB, as a binary type, allows any type of data so lowercase is meaningless within the file.
- The attribute ASQN is always enabled, and cannot be disabled.
- When BLOB and CLOB data is read from the database, files are automatically created in the directory structures under the LPTH= directory (for information, refer to Standard X_RUN Parameters).
Platform Considerations
- Refer to Platform Considerations in 1.1.1 Field Type Considerations.
Tips & Techniques
- The recommended design when using BLOB and CLOB fields is to put them in a separate file from the rest of the fields using the same key as the main file. This forces programmers to do separate IOs to access the BLOB and CLOB data, thus reducing impact on database performance from indiscriminate use of this data. It is also the most portable design ensuring that the non-BLOB and non-CLOB data can be quickly accessed at all times.
- The LOB directory files created on read are occasionally not deleted at the end of your LANSA session. A special process, *LOBCLNUP, can be executed occasionally to cleanup the LOB directory structure. The process needs to be run by a user with sufficient authority to remove files that may have been created by other users. For example, on IBM i, use the following command: LANSA REQUEST(X_RUN) X_RUNADPRM('PROC=*LOBCLNUP')
Also See