Delete (statement)

The Delete (DEL) statement removes one record from an internal file. For deleting lines from a program, see the Delete Command.

Comments and Examples

An internal file must already be opened and assigned a file number before DELETE can be used. Records are marked or flagged for deletion using a system-controlled byte for deletion, which is contained in each record in an internal file. The DELETE statement makes the data from a record unusable, but does not recover the space for that record. The easiest way to recover the space from deleted records is to use the Copy command with the "-D" option.

Also see "READ File" statement discussion for details.

The following line will delete a record, after the file has been opened:

00530 Delete #1,Key=badrec$: Nokey KeyNotFoundLine

Where badrec$ is the key for a record selected by the operator for deletion.

Syntax

DELETE #<file number> [{,REC=<numeric expression>|,KEY=<string expression>}] [{,RESERVE|,RELEASE}] : [<error condition> <line ref>][,...]

Defaults

1.) Delete the last record read.

2.) Release all previous locks; unlock current record.

3.) Interrupt the program if an error occurs and ON is not active.

Parameters

The file number of the file from which the record is to be deleted must be identified with the "#file number" parameter.

The optional "REC=num-expr" clause is used with internal files opened for relative or keyed processing, or with external files opened for relative processing. After the numeric expression (usually a simple numeric variable or constant) is evaluated to an integer, the system performs an implied read and the record with that record number is deleted. If "REC=num-expr" is not specified, the record deleted will always be the last record which was read.

The optional "KEY=string-expr" clause is used with files opened for keyed processing; after the string expression is evaluated (usually a simple string variable or constant), the system performs an implied read and that record is deleted. If "KEY=string-expr" is not specified, the record deleted will always be the last record which was read.

The "RESERVE" and "RELEASE" parameters specify record locking rules for multi-user systems. "RESERVE" instructs the system to hold all previous locks and lock the current record. "RELEASE" releases all previous locks and unlocks the current record.

Technical Considerations

1.) Relevant error conditions are ERROR, Exit, IOERR, NOREC, and NOKEY.

2.) DELETE can only be used with an internal file that is opened OUTIN.

3.) In the KEY=n$ clause, the only form allowed is KEY=n$. KEY>=n$, SEARCH=n$, and SEARCH>=n$ are not allowed, as their results (partial and "next greater" matches) are unpredictable.

4.) For SEQUENTIAL processing, the record deleted is always the last record that was read. After a DELETE, the next record read will be the next active record after the deleted record.

5.) When reclaiming the space from deleted records using the COPY command with the -D option, you must rebuild all indexes for that file. The COPY is likely to change relative record numbers, making the index file entries invalid.

6.) The REC= parameter may be used with files opened for either relative or keyed processing. Using REC= in this manner will not disturb the key position in the file.

7.) When deleting the record that was just read, you should not use the REC= or KEY= clauses. They will generate an unnecessary READ that slows down programs, especially with KEYED processing.

8.) When deleting a previously read record on a multi-user system where the file has been opened SHR, you must lock the record before deleting it or Business Rules will return a record not locked error.

9.) The positional parameters FIRST, LAST, PRIOR, NEXT, and SAME can be used with the DELETE statement, as well as with READ, RESTORE and REWRITE.

10.) The DELETE statement may be used to delete any anchor record or subrecord from a linked list. The DELETE statement must be preceded by a successful READ of the record to be deleted.

Business Rules will automatically update the next and previous record pointers (held in the first eight bytes of each linked record) of the affected records when a linked list record is deleted. If a linked list's anchor record is deleted, the next record in the list will become the anchor record. Also, the value of KREC will be updated to return the value of this new anchor record, no matter where the file pointer is in the list.