HP 3000 Manuals HP 3000 Manuals
Removing LONG Column Data with a DELETE [WHERE CURRENT] Command
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.
DELETE FROM PartsTable WHERE PartName = 'hammer'
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.
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 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.