Consultor Eletrônico



Kbase P150949: Loading an incremental .df fails with a 7996 error on a specific database.
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   11/26/2009
Status: Verified

SYMPTOM(s):

Loading an incremental .df fails with a 7996 error on a specific database.

Unable to update the Field Map for table '<tablename>'. (7996)"

Error occurs when loading a .df using a 4GL program.

The issue can be duplicated amongst various copies of this database.

The database they are experiencing the issue with is their development database.

The .df file for the table that the new delta.df is making modifications to shows that there is a field within the table that contains FOREIGN and FIELD-MISC entries that do not exist in the .df from the same table in the production database.

Example:

ADD FIELD "fieldname" OF "table name" AS integer
FORMAT ">>>>>"
INITIAL "0"
POSITION 60
MAX-WIDTH 4
VIEW-AS ""
ORDER 1520
FOREIGN-CODE 0 <-----------------
FOREIGN-ID 0
FOREIGN-NAME ""
FOREIGN-RETRIEVE no
FOREIGN-SPACING 0
FOREIGN-TYPE ""
FOREIGN-XPOS 0
FOREIGN-SEP ""
FOREIGN-ALLOCATED 0
FOREIGN-MAXIMUM 0
FIELD-MISC16 0 <------------------
FIELD-MISC17 0
FIELD-MISC18 -1
FIELD-MISC22 ÿ"
FIELD-MISC23 ÿ"
FIELD-MISC24 ÿ"
FIELD-MISC25 ÿ"
FIELD-MISC26 ÿ"
FIELD-MISC27 ÿ"
FIELD-MISC28 ÿ"


FACT(s) (Environment):

The .df can be applied to the production database.
OpenEdge 10.1B03 Service Pack
Solaris

CAUSE:

The table that the delta.df file is trying to modify contains entries that are not for a Progress database. The entries are FOREIGN and are associated with a schema holder database. These entries would have had to have been made by someone taking a copy of a field from a schema holder database .df file and applying it to a Progress database.

FIX:

Dump the .df file for the offending table by using the dictionary and selecting dump data definitions and then selecting the appropriate table.
Dump the data for the offending table using either the dictionary or a binary dump of the table in question.
Then drop / delete the offending table.
Modify the .df associated with the table to no longer contain any of the FOREIGN entries as well as the FIELD-MISC entries.
Then load the modified .df file back into the database using the data dictionary and selecting load data definitions.
Then load the data back into the database.

Then load the incremental .df that was failing originally. The delta.df should now be able to be loaded into the database as the offending entries from a field within that table have been removed.