qad_wkfl

[Chris Kelleher]

I know qad has used the qad_wkfl to store data created in menu 35.2 since
7.3e. It is a permanent cross reference between site id and Trading
partner's EDI id for that site. For these records qad_key1 = "sfst_det".
These records may represent significant effort for someone. Delete at your
peril.

As for the user_wkfl, many users and bolt on applications store permanent
records in this file since it is the only place to do that without changing
the schema.

I would say don't add, change, or delete these records unless you understand
what they are for and what you are doing. Call qad for qad_wkfl questions
and other applications houses for the user_wkfl.

Richard Rutherford, Consultant TRW ISCS
rlrutherford@home.com
Tel 510 787-3240 Fax 510 787-3160

 

[Chris Kelleher]

David,

Therein lies the real issue. You found a bunch of records with a common
key format. Therefore, they are all likely related, and a decision can be
made about them and their continued existence.

Please recognize that I'm not entering the discussion of whether or not
qad_wkfl should be used for these various purposes. There are a lot of
facts, opinions, and issues on the matter, and the main fact is that
qad_wkfl is currently used for a lot of things. That can't and won't be
changed overnight.

Under no circumstances should *ANYONE* remove *ALL* records from the
qad_wkfl (unless, of course, you plan on rendering your database
inconsistent). If any records are removed, you should only use an
established tool (like the orphaned login record removal program available
in current versions) or work with the guidance of QAD support or someone
else who is willing to sacrifice their favorite body parts in case
something goes wrong. Who wants to be the first to announce to the CFO
that you've just lost all the period closure information since the start of
your implementation, many many moons ago?

Remember that the qad_wkfl has a six-part key, giving 720 variations for
using them, if my math memory serves me correctly, and that's before you
start checking for specific values in each of the keys. That means well
over millions of application possibilities, which means millions of problem
possibilities... Okay, so they're not all used. But the point is, which
body part are you willing to wager that your actions won't cause problems?

For questions about specific records and whether or not they can be
deleted, check the Solution Profiler first and support next.

Good luck.

Scott
Okay, so I'm not supposed to be here. This one slipped through before I
unsubscribed, and I'm waiting for my son to decide it's time to sleep...
===============================================================
Scott M. Dulecki /* 1998061901 */ +1 616 975 6322
Product Manager scott_dulecki@qad.com
QAD, Inc. http://www.qad.com
1188 East Paris SE Grand Rapids, MI 49546 USA

Next Michigan Progress Users Group: 17 November 1999

All opinions are my own, and don't necessarily reflect those of
any other living being.
===============================================================

 

[Chris Kelleher]

David,

Part of the reason the qad_wkfl exists is for the same reason that the
usr_wkfl exists -- to create space for an additional table as needed,
without needing to actually add the table. Adding a table, of course,
presents CRC challenges and generally lead to massive code recompilations.

Our intent with most things that we put into the qad_wkfl is to move those
into separate tables at the next opportunity, which is normally a schema
change. We've done this in some cases, but not in others. I can't give
you any rationale as to why we have or haven't made the switch; it's very
project-dependent.

You've hit the key element: someone from QAD directed you to remove
qad_wkfl records. I'm surprised that they directed you to remove all of
them, but without knowing the exact problem and situation, I can't
second-guess the folks in support, and I won't. If they make a mistake,
they also get the privilege of correcting it...

BTW, I'm not trying to "target" you in these responses. You are simply
bringing up critical questions and issues that customers run into, and I'm
using your emails as the basis for trying to clear the air.

Good luck.

Scott
===============================================================
Scott M. Dulecki /* 1998061901 */ +1 616 975 6322
Product Manager scott_dulecki@qad.com
QAD, Inc. http://www.qad.com
1188 East Paris SE Grand Rapids, MI 49546 USA

Next Michigan Progress Users Group: 17 November 1999

All opinions are my own, and don't necessarily reflect those of
any other living being.
===============================================================