Syntax for the DELETE and DELETE WHERE CURRENT commands is unchanged
for use with LONG
columns. It is limited for the DELETE command in that a LONG column
cannot be used in the WHERE clause.
In the following example, any rows in PartsTable with the PartName of
hammer are deleted.
When LONG column data is deleted, the space it occupied in the
DBEnvironment is
released when your transaction ends.
But any data file selected earlier still exists on the operating system.
You may want to design
a "cleanup" strategy for such files that are no longer needed.
Coding Considerations |
 |
File versus Random Heap Space
Depending on your application, you might want to use a file or random heap space
as your input or output device. Random heap space may provide faster data
access. Consider
how much random heap 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 you could create a maintenance
procedure.
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
group,
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
random heap space
available for your use in relation to the size and
number of LONG columns to be selected or fetched.
