Field xxx causes duplicate database data

The warning informs you of a special database situation that is not advisable. The XFD builds and the interface operates correctly.

This warning means that your record definition should be restructured. Your current definition is set up in such a way that:

  1. You have overlapping key fields, and
  2. Both keys must be represented in the database as separate items.

Database Connectors handles this situation by keeping the overlapping keys updated simultaneously, so that they always have the same value. However, the warning alerts you that you have the same data represented twice in the database. This is dangerous, because someone at the site might access the database via SQL and accidentally change only one of the keys.

Here's an example of the problem and a description of how to correct it (the example assumes that both key-1and key-2 have been declared as keys):

01  order–record.
    03  key–1.
        05  field–a                  pic x(5).
        05  field–b                  pic 9(5).
        05  key–2
            redefines field–b        pic x(3).

This example generates the warning message.

Because key-2 is a key, it must also be represented in the database. It doesn't correspond exactly to any other data field, so it must be entered as a separate column in the database.

In the COBOL view of the file, key-1and key-2 overlap. But the requirements of database storage force the same data (known to COBOL as field-b) to be physically represented twice in the database. Any updates to the data from any COBOL program correctly updates both columns. Updates from outside of this COBOL program carry no such guarantee.

Resolution

In this example, you can correct the situation by breaking field-b into two columns, so that key-2 corresponds exactly to another data field:

01  order–record.
    03  key–1.
        05  field–a                        pic x(5).
        05  field–b.
            07  field-b1                   pic x(3).
            07  field-b2                   pic 9(2).
        05  key–2
            redefines field–b              pic x(3).