Page History
...
Please review the general 1.1.1 Field Type Considerations.
Field Definition Rules
Rules for defining a BLOB in the repository are:
...
- 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 clearly indicates that changing the field's " value " 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 a 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')