Look in the OLD fields

by James
(Buffalo, NY)

We have a vendor who's wonderful software is written in COBOL with a semi-relational structure (the relationships are not enforced and cannot be relied upon). We routinely (by that I mean constantly) need to access their underlying data so we are pretty familiar with their tables.

When working on a project using one of their built-in APIs, I went to the target table for the data to check that it was correct. I could find the record that should have been created but some of my data was missing. I had some data that I would expect to see in fields named like: PAYAMT, PAYDAT. I was puzzled and started looking at all the columns (there are many) and I saw my data. It was in fields named like OLDPAY, OLDDAT. I kind of scratched my head but didn't think that much of it. This vendor routinely adds DUPFOO (duplicate FOO) fields to columns, especially keys. I just started expecting to see the data in the OLD fields.

Later, in testing, I again couldn't find my data for a transaction. For some of the records, the data was going into the other fields (PAYDAT, PAYDAT) but not into the OLD fields. I muttered some obscenities and modified a report union the table against itself using which ever fields the data was in. But I couldn't imagine any good reason to do something so goofy. Why would you ever need to have two sets of fields that are exactly the same (exactly) but only use one or the other, never both?

Much later, I received a ticket about how the process I had worked on was entering 0 values for all amounts based on a screen written by the vendor. I looked in the database at the record in question and sure enough, the data was in the 'new' fields. Apparently the vendor didn't get the word out to all their developers about their sophisticated table design.