Progress 8.2C CHUI
Mfg/Pro 8.5F
Dear Peggers and QADers:
While our plain-vanilla Mfg/Pro system was being implemented, we had a
couple of contract programmers here to help us with some reports and
side systems. These programmers made heavy use of the usrw_wkfl,
using it where (I think) they should have been using temp tables; and
also storing persistent transaction data out there. When I saw what
was going on, I raised a red flag to the contractors, and then to my
boss; but the contractors insisted that there was no reason to be
concerned. And so the development continued, with the Workfile being
used in dozens of programs.
After the contractors left, we began to have problems. First we
discovered that obsolete records were not being deleted and at the
height of this Workfile use, we had several hundred thousand records
out there; and since some of the data was persistent, we couldn't just
blow it all away some night.
We also learned that record keys were not properly used and the entire
Workfile was being read on queries that should have been a bracketed.
Of course, with the large amount of data on usrw_wkfl, reports were
taking a long time.
We also began to experience chronic contention between applications,
with programs reporting that the usrw_wkfl table was locked by another
user. It was a nightmare.
And so we decided to replace the Workfile in all our programs with
temporary tables or with permanently-defined tables, as the case
required. Our problems went away.
Now we are considering using the usrw_wkfl, once again, but this time
as a general table file--a place to store a small number of records
for a given application. Control records, for instance; bits of data
that must be saved for the next run of the application; the kind of
stuff you might find in a .ini file. Of course, we will use the table
keys properly.
The reason we want to do this is so that we don't have to create a
whole bunch of little one-or-two-record tables; also, we have a
dickens of a time getting these tables installed into our 24x7
production system, since a table cannot be added or modified if anyone
is using the system (we have a programmer getting up in the middle of
the night, trying to install a new table or modify an old one; even
then, he can't always do it. This is a nightmare, too.)
Question: Is it a good idea to use usrw_wkfl as a general table file?
What are the pros and cons?
TIA
Jack Kaufman
Sr. Programmer/Analyst
Systems Department
Ingersoll-Rand Corporation
101 North Main Street
Athens, PA 18810
Phone: 570-882-0366
Fax: 570-882-0452
Email: Jack_Kaufman@ingerrand.com
Mfg/Pro 8.5F
Dear Peggers and QADers:
While our plain-vanilla Mfg/Pro system was being implemented, we had a
couple of contract programmers here to help us with some reports and
side systems. These programmers made heavy use of the usrw_wkfl,
using it where (I think) they should have been using temp tables; and
also storing persistent transaction data out there. When I saw what
was going on, I raised a red flag to the contractors, and then to my
boss; but the contractors insisted that there was no reason to be
concerned. And so the development continued, with the Workfile being
used in dozens of programs.
After the contractors left, we began to have problems. First we
discovered that obsolete records were not being deleted and at the
height of this Workfile use, we had several hundred thousand records
out there; and since some of the data was persistent, we couldn't just
blow it all away some night.
We also learned that record keys were not properly used and the entire
Workfile was being read on queries that should have been a bracketed.
Of course, with the large amount of data on usrw_wkfl, reports were
taking a long time.
We also began to experience chronic contention between applications,
with programs reporting that the usrw_wkfl table was locked by another
user. It was a nightmare.
And so we decided to replace the Workfile in all our programs with
temporary tables or with permanently-defined tables, as the case
required. Our problems went away.
Now we are considering using the usrw_wkfl, once again, but this time
as a general table file--a place to store a small number of records
for a given application. Control records, for instance; bits of data
that must be saved for the next run of the application; the kind of
stuff you might find in a .ini file. Of course, we will use the table
keys properly.
The reason we want to do this is so that we don't have to create a
whole bunch of little one-or-two-record tables; also, we have a
dickens of a time getting these tables installed into our 24x7
production system, since a table cannot be added or modified if anyone
is using the system (we have a programmer getting up in the middle of
the night, trying to install a new table or modify an old one; even
then, he can't always do it. This is a nightmare, too.)
Question: Is it a good idea to use usrw_wkfl as a general table file?
What are the pros and cons?
TIA
Jack Kaufman
Sr. Programmer/Analyst
Systems Department
Ingersoll-Rand Corporation
101 North Main Street
Athens, PA 18810
Phone: 570-882-0366
Fax: 570-882-0452
Email: Jack_Kaufman@ingerrand.com