qad_wkfl

[Chris Kelleher]

Probably a very simple answer to this but.....

I have a test system that is being run to test some work
that was done to a module within QAD. Everything was
great last month, but with the new month, we cannot close
any work orders because we check the qad_wkfl
(qad_key1 = "GLCD_DET") to see if the period is open.
I went into the editor and noticed that, true enough, there is
a record for every period up to last month, but nothing after that.

Question: How do I use QAD (Version 8.3C) to create these records ?

 

[Chris Kelleher]

I don't know how to check for an open period, but I know you do NOT use
qad_wkfl.
You should be able to delete every record in that workfile any time you have
all users off the system, with no ill effects. Programs should not rely on
qad_wkfl (or any other *_wkfl) from one menu selection to another.

David Takle
Software Consultant
Find First Consultant, Inc.

 

[Chris Kelleher]

Can someone from QAD verify this? It was my impression that QAD often
uses qad_wkfl to store certain values without having to do schema
changes, so they can add features in "letter" releases.
---------------
Paul T. O'Leary
Evco Plastics, a leader in plastics injection molding
DeForest, WI USA

 

[Chris Kelleher]

This is not true. qad_wkfl is used for many functions within MFG/Pro. Work
Order processing for one (at least in my v8.5E anyway). Its usage probably
changes with each release.
A quick look at the data will show you the records.

for each qad_wkfl no-lock:
disp qad_wkfl with 2 col 1 down.
end.

Gee, we miss Scott D. already.

If you're having some trouble that you think is related to the qad_wkfl
table, call QAD tech support before doing anything to it.

- Tris Hopkins
Flexalloy-Textron

 

[Chris Kelleher]

I agree with Paul. A least I know qad_wkfl holds info that users enter on
22.7.1 Simulation Criteria Maintenance in V7.4h which I don't think is a
good idea to delete when users are off the system.

Lily Wang

 

[Chris Kelleher]

I agree with the others not to touch the qad_wkfl. That is reserved
for QAD use. Have you tried looking at your g/l calendar on the
25.3.4 (G/L Calendar Maintenance)?

Debi Loope
PI Inc.

 

[Chris Kelleher]

The question is not whether or not they use qad_wkfl, or for how many
functions.
The question is whether or not these are *temporary* or *permanent* records.
Your example code is unfortunately not very instructive, because due to a
number of bugs in the code, qad_wkfl records get orphaned all the time.
On at least one occassion, we were instructed by QAD to delete all of the
qad_wkfl records to resolve a problem. That would lead me to believe they
are not very static.
The only qad_wkfl records I know of that are intended to last the duration
of a session are those where qad_key1 = "mf1.p". Those records identify the
unique session id: qad_key2 = mfguser. As far as I know, all other qad_wkfl
records only need to exist for the duration of a particular Menu-level
procedure.
The only exception to that I have ever seen is that under discussion in this
thread, and I am a bit baffled by it. If indeed there are permannent
qad_wkfl records, I would really like to know about it. But at this point I
remain skeptical.

David Takle
Software Consultant
Find First Consultant, Inc.

 

[Chris Kelleher]

Gino,

somewhere between 7.3/8.3 and 7.4/8.4 QAD introduced a change in the way the GL periods were closed. On 7.3 you could close the GL period for all the "automatic" modules, and for the GL. They later added the functionality that allows to close each individual module (IC, WO, SO, etc), but had to use the qad_wkfl because they couldn't change the schema at that point in time.

> Question: How do I use QAD (Version 8.3C) to create these records ?

Can you go to 25.3.4 and look what are the open GL periods and modules for your entity? You'll probably find the answer there. GLCD_DET is the general ledger calendar detail file.

HTH. Feel free to e-mail me again if needed.

Carlos


--
=======================================================
Carlos Colmenares http://www.protech.com
Senior Programmer ccolmenares@protech.com
Protech Systems Inc. (609) 714 0700 - Ext. 50
PEG Member 1999061404
I'm the only one to praise/blame for whatever I do/write/say
=======================================================
"Quick to judge, quick to anger - slow to understand
Ignorance & prejudice & fear walk hand in hand" RUSH - Witch Hunt.

 

[Chris Kelleher]

The use of qad_wkfl is most likely heavily dependent on the version you're
running.

A quick check shows that there are almost 309,000 (approximately 37MB)
qad_wkfl records in our v8.5E database. I find it hard to believe that QAD
would write code so poorly that such a large numbers of records would become
orphaned in that table.

- Tris Hopkins
Flexalloy-Textron

 

[Chris Kelleher]

Oh, yes they can.
We once had to remove 1.9 million orphaned records.
That was under QAD's direction.

David Takle
Software Consultant
Find First Consultant, Inc.

 

[Chris Kelleher]

Hi David,

Check out my example of 22.7.1 Simulation Criteria Maintenance. It is a
permanent record. (unless you have different definition of permanent.) You
can look into the inquiry program of 22.7.2. It's only from qad_wkfl.(It's
still the same in V8.6C) I think in your previous case, you probably
didn't use Forecast Simulation Module.

Thanks,
Lily Wang

 

[Chris Kelleher]

I'm no longer officially part of QAD, but the response is accurate.
And since Scott Dulecki isn't around for a while because of his
new baby, I'll respond.

Do NOT delete all records in qad_wkfl. You MAY delete all records
in usr_wkfl if you know of any and all applications (external to
QAD applications) that put them there.

If you need to get rid of specific records, look for the correct
key for the records you want to get rid of, and delete them
separately. (But of course, test to make sure that some other
portion of the application might need them.

Paul is correct in that many QAD programs still stuff records
in qad_wkfl, even though they should have been moved to the rest
of the schema years ago.

Bruce

 

[Chris Kelleher]

In 7.4I qad_wkfl records are created when work order is accounting closed. These are permanent and are required to identify whether a particular work order/lot is accounting closed

Geetha

 

[Chris Kelleher]

I stand by the premise that qad_wkfl records are designed to persist.
But I'm in David's corner on this one, for another reason.

Case in point: I just discovered a slew of records with qad_key1 =
"ro_det" + ro_routing + " " + ro_op, qad_key2 = ro_start (or at least
that's the most obvious interpretation). Most of them are for ro_det
records that we deleted back when Ike carried his own golf clubs (okay,
I exaggerate; translation for those outside the US: "a long time ago").
These are, indeed, orphaned records. But back when the "parent" ro_det
records existed, they were probably needed, and not just during a run
of Routing Maintenance.

My guess is that, in many cases, when they jam code into letter
releases that uses qad_wkfl, they don't re-visit the code that deletes
the parent record, where they _should_ add code to delete the qad_wkfl
record. To avoid global warming, I'll stay off my soap-box about what
this implies re. code quality.

So yes, qad_wkfl does tend to be an orphaned-record hot-spot. But no,
they aren't necessarily orphaned as soon as the user returns to a menu.

Y'know, with the temp-table capacities of today's supported Progress
versions, there's no longer a need to use a DB table for records that
don't persist beyond a menu selection.

 

[Chris Kelleher]

Thanks all, but I think that I may have mislead people.

What I wanted to do was create the records. Not delete
them. I was able to create them with the help of the
program in 25.3.4 (G/L Calendar Maintenance)?

Thanks again.

 

[Chris Kelleher]

I just checked. The period closed information is stored in qad_wkfl. I think
deleting all these records would be a bad thing.
Charlie

 

[Chris Kelleher]

There are some qad_wkfl records with qad_key1 = some integer value and qad_key2 = ?. Can I for sure delete these records?

Geetha

 

[Chris Kelleher]

Can't speak to that one.
But I just came across another case here in which there were 40,000+ records
in qad_wkfl where qad_key1 BEGINS "soivpst". They were created by ardrmt.p
as a result of patch G1L8 on 01/30/96. That patch was then commented out by
patch G2G2 on 9/30/96. The records are no longer used anywhere.
Unfortunately, we ended up with a version of the program that was creating
the records when we accepted a 3rd party implimentation of VERTEX sales tax
software. So I had to comment out the code again and delete the obsolete
records.

David Takle
Software Consultant
Find First Consultant, Inc.

 

[Chris Kelleher]

Ex-QAD employee (installation, custom programming, etc.)

Do not ever *#$&) with the qad_wkfl. Don't delete records, don't add
records, don't use it for your custom programming. For site use, use
usr_wklf.

 

[Chris Kelleher]

I usually never *#$& with the qad_wkfl, but there is a routine that I run on
occasion (don't have the code in front of me) that safely removes phantom wkfl's
(users that exit abnormally , etc..) that can slow down the login process..
other than that , definitely heed Dana's warning and do not $$#%%## :{ with the
qad_wkfl.