| Translate Value Changes | KEVIN RESCHENBERG
07-26-2006 |
Some of my previous posts have referred to the issue
of protecting our development environments. Without
adequate safeguards, unwanted changes to objects
can be made and could then make their way into production.
That's why it's a little surprising to see that at newer
releases—I'm using HRMS/HCM 8.9 now—any user
with the proper permissions can make changes to the
translate table through a convenient page in the
application. It's always been my opinion that translate
values should be placed firmly in the "developers only"
category.
The translate table (XLATTABLE at earlier releases and
PSXLATITEM at later ones) has three main purposes.
First, it's a convenient way to store and retrieve
effective-dated descriptions for codes without the
need for a separate "prompt" table. Second, the table
supports language translations for these descriptions.
Third, just as with other prompt tables, the translate
table limits the values a user can choose for a particular
field.
So what is the difference between the translate table and
any other simple prompt table? Aside from GUI differences
that aren't really relevant here, I think that the translate
table has always been reserved for relatively static values
that are unlikely to require frequent changes. Think of the department
table. This table must be available for updates
by users as new departments are created or old ones
undergo name changes. It would be inconvenient to store
department codes as translate values (even if we did not
need associated information other than the department name).
But codes such as benefit plan types, which are more
static and which control processing, are good candidates
for the translate table.
Because the translate values were hidden away and available
only to developers, programs traditionally could rely on the
static character of these values. In other words, a program
or SQL statement could assume that certain values existed
and could go directly to the table to retrieve descriptions.
More importantly, a program could use a CASE-type structure
to deal with these values.
Allowing easy updates to the translate values can break
programs in two ways. First, a deletion from the table
can break SQL joins. SQL that innocently uses a natural
join with the translate table will drop rows if a translate
value disappears. Even additions to the translate table
will break programs that use a CASE structure to handle
various codes. A new code permits field values that the
program will not be prepared to handle.
Even if access to the table is properly controlled, we need
to provide for migration of the values. That should be done
through App Designer.
Users will probably be happy to see this new convenient
access to the translate table, but we need to be careful
with it. You might consider just restricting access through
a permission list change.
|
