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 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 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
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.
To place data in
shared memory
use the wildcard option ($) because
Pascal cannot specify random heap space address.
The actual
shared memory
address will be placed in the LONG column descriptor.
Refer to this address when using SELECT and UPDATE commands.
