Consultor Eletrônico

Status: Verified

FACT(s) (Environment):

Progress 8.x

SYMPTOM(s):

Binary dump performed from Progress 8.x.

Binary load into Progress 8.x and 9.x fails.

The number of fields in the schema is <num>, expected <num>. (6271)

Binary Load failed. (6255)

CAUSE:

Columns had been deleted from a table (preferably somewhere in the middle of the physical record).

The error occurs because the number of fields recorded within a Progress 8.x binary dump header also includes any deleted fields, and the .DF file generated from the database contains only existing fields.

This mismatch between the binary dump header information and the newly created table schema causes the binary load function to fail (in either Version 8.x or 9.x).

CAUSE:

Bug #19990802-035

FIX:

The issue is fixed in the last patch to 9.0B, release 9.1A and 9.1B.

The schema can be altered to contain the same number of fields as stated in the above error, the binary load function will run without error, however the target table will be corrupted (the records loaded into the table contain place-holders for the deleted fields).

The Version 9.x binary dump and load process does not experience the problem because the corresponding .DF file contains physical position information (RPOS) that is not available to a Version 8.x .DF file.

The following 4GL program can be used to determine whether a binary dump can be performed on a specific table:


define var t-position as integer.

for each _file where _file-num > 0:
    t-position = 1.
    for each _field of _file no-lock BY _field._field-rpos:
       if (t-position + 1) <> _field._field-rpos then do:
            display _file._file-name "RPOS error".
            leave.
        end.
    t-position = t-position + 1.
    end.
end.