File versus Shared Memory |
 |
Depending on your application, you might want to use a file or
shared memory as your input or output device. Whereas shared memory may
provide faster data access, a file may provide greater security.
Consider how memory will be used by other processes and how much memory
will be available. What about using a file as an I/O device?
You might ask yourself the following questions. Whom do
you want to access the file during and after the application transaction is
complete? How will it be "cleaned up" when it is no longer being used;
perhaps the overwrite option would be helpful or another maintenance
procedure.
File Naming Conventions |
|
When a LONG column is selected or fetched, data goes to the output device
you have specified at insert or update time. In the case of a
file, because this output device name
can be completely defined by you, partially defined by you, or assigned
by ALLBASE/SQL, you may want to consider whether or not
naming conventions are necessary. For instance, if your application is
such that you can always give the same name to your LONG column output
device as you give to the standard column you use in the WHERE clause,
no need exists to extract the device name from the LONG column
descriptor when you select or fetch it.
For example, assuming your WHERE clause uses the PartsTable
PartName column, the data_file example in the previous section, "Example Data File,"
uses this strategy. (Your application might still require information other than a file name from the descriptor area.)
Considering Multiple Users |
|
With multiple users reading the same LONG column data, it is
preferable for each user to run the application in a local area.
This can prevent file access problems.
If several users must access the same data from the same
directory, you might want to use the wildcard option ($) and avoid using the overwrite option (!).
Deciding How Much Space to Allocate and Where |
|
Remember to consider the space requirements of any DBEFileSet used for
LONG column data. For example, suppose you execute an INSERT or UPDATE command for a
LONG column defined as VARBINARY. If inadequate space is available in the
database for the new data, an error message is returned to your program,
and the transaction is rolled back. In this case, you can CREATE another
DBEFile and add it to the appropriate DBEFileSet.
You will also want to consider the amount of
shared memory available for your use in relation to the size and
number of LONG columns to be selected or fetched.
The actual shared memory address will be placed in the LONG column descriptor.
Refer to this address when using SELECT and UPDATE commands.
