BLOB Fields and Large Text Fields
CopiaFacts database support is not designed to work with a number of complex field types. If you need to deal with very complex data or work with complex data relationships, you can always write a custom DLL and interface it to CopiaFacts. However, we recommend limiting this sort of processing in IVR applications because it tends to be slow and ties up a valuable line and system resources. If you must perform lengthy processing, we suggest breaking it down into manageable tasks and playing messages to keep the caller informed of your progress. Some supported voice boards may be able to play messages asynchronously while other script processing takes place.
When you retrieve a memo field, it may contain embedded newline sequences. Variables into which such fields are read may automatically be written into an FS file, and if the field still contains newline sequences (carriage-return and/or line-feed characters) this will cause a failure when the file is next read by CopiaFacts.
It is essential that you remove newline sequences from any memo field you retrieve from a database, even if you do not use the field in your application. There are two ways to do this:
•You can assign an empty value to the field. For example:
$set_var CLIENTS%NOTES @EMPTY
$set_var CLIENTS%NOTES $br
If your application updates or adds new records containing a memo field, you will normally need to convert the newlines in the field value after you have updated the database. You must also assighn an empty value to, or convert, any variables to which you have assigned the memo field value while it still contained newline sequences.
Processing Binary Fields
Since BLOB fields usually contain binary data, they cannot be stored in CopiaFacts internal variables. These variables are limited to approximately 8,000 bytes of data and cannot store data with embedded null bytes. Instead, you should specify files to hold any data read from or written to BLOB fields. You may specify a list of database fields that are to be read from external files or written to external files. You specify these fields using the following command syntax:
$set_var DB_SELECT "STORE=Field1[FileSpec1];…Fieldn[FileSpecn]"
Each entry in the specifier list is separated from the others by a semicolon. An entry consists of a field name followed by a file specification in square brackets. The file specification can be a literal file name, a CopiaFacts variable reference such as @MYFILE, or an indirect reference to a CopiaFacts variable using the asterisk (*) followed by a CopiaFacts variable name such as *MYFILE. The difference between a variable reference and an indirect reference is that the variable reference is resolved at the time the STORE command is executed, whereas the indirect reference is resolved each time a field in the list is read or written. The indirect reference allows you to modify the contents of the CopiaFacts file specification variable between database operations without executing additional STORE commands to tell CopiaFacts to use a different file for reading or writing data from the field.
The use of the STORE command allows you to use external storage as a staging area for large amounts of data that are read from or written to specific columns in your database records. When you retrieve a record that contains one of the fields, the data from the field is written to the file you specify. If the file exists, it is overwritten. If no data is present in the field, the target file will be erased. So the presence of the target file indicates that data was present in the source field. When you update or append records to the database containing one of these fields, the data is read from the specified file and placed in the field. However, it is possible that your database provider does not support these field types or operations on them. In that case, you will get an error trying to read or write these fields to/from external storage.