Consultor Eletrônico

Status: Verified

FACT(s) (Environment):

OpenEdge 10.0B

SYMPTOM(s):

Truncate Area fails with Can't find template record

Storage Area is not the Schema Area

Storage Area is a Type II architecture with Tables

Type II Storage Area with only Indexes can be truncated

CAUSE:

Bug# 20040729-007

CAUSE:

This is a known issue in the Type II Storage Area architecture. The proutil area truncate operation caches the template record for each table in the area to be truncated. In OpenEdge 10.0B we were erroneously using the Area Object descriptor rather than each individual Table Object descriptor to validate the fetch of template records of the tables it read causing the failure.

FIX:

Upgrade to 10.0B01 or later

or

Upgrade to 10.1A or later
Once upgraded, repeat the Storage Area truncation:

$ proutil dbname -C truncate area "<Area-name>" -G 0
If you are not able to upgrade:

WORKAROUND A:

If the associated index area has NOT been truncated:
Run mulitple 4GL deletes in batches of (say) 10000

Example:
DEFINE VARIABLE i AS INTEGER NO-UNDO.
FIND FIRST <table-name> EXCLUSIVE-LOCK.
main:
DO WHILE true:
i = 0.
DO TRANSACTION WHILE i < 10000:
i = i + 1.
DELETE <table-name>.
FIND NEXT <table-name> EXCLUSIVE-LOCK NO-WAIT NO-ERROR.
IF NOT AVAILABLE <table-name> THEN LEAVE main.
end.
END.

Once this operation is completed, move the table to a Type I Storage area (online) with the "proutil dbname -C tablemove "Type I Area Name"

WORKAROUND B:

If associated indexes are truncated, either:
dump and loading everything but the table(s) in that specific area - since the object of truncating the area was to effectively delete all records associated
or
rebuild the primary index associated with the table in that area
then
run multiple 4GL client session deletes (as above)