Open Query and OVRDBF dilemma.

[jdeuser2001]

Hi folks,

I have been doing JDE World programming for a long time and have encountered this problem before, but forgot the solution :-( Can anyone help with finding a solution to this problem?

1. Standard Dream Writer CLP executes OVRDBF F4801 SHARE(*YES) prior to calling Program A. Dream Writer's Open Query is specified with the following parms: Sequential=N, Open for Output=Y, Open for Update = Y, Open for Delete = N.

2. RPG pgm A reads F4801 (open query) sequentially and calls RPG pgm B (std. JDE X4201WO) to add new work orders to F4801.

3. Program A calls Program C (std. JDE P31410) to attach parts list and routing to newly created Work Orders. Program C fails on trying to read (chain) to newly created Work Orders in F4801 due to the shared access path created over F4801 in step 1.

Question: How do you make program C look at the entire F4801 and not the Overriden F4801 with the open query?

Thank you for your help!

 

[John_Dickey]

Well, one sure way is to have Program C use a logical file over F4801, instead of the physical file.

John Dickey
Accounting Systems Administrator
White-Rodgers, division of Emerson
8100 West Florissant Avenue
P.O. Box 36922
St. Louis, MO 63136-9022
314-553-3067

 

[jdeuser2001]

Re: RE: Open Query and OVRDBF dilemma.

John,

Indeed. Unfortunately, there is no other logical to use. F4801 physical is keyed by WADOCO which is the access path that Program C needs. I suppose I could create another logical file, i.e. F4801LZ, keyed by WADOCO, and modify program C to use it. Unfortunately, again, program C is a standard JDE program, used several places, and I am trying to stay away from modifying it (unless absolutely necessary.) Program C is P31410.

Is there another way of keeping Access Paths unique?

Thank you for your help!

Will.

 

[John_Dickey]

RE: RE: Open Query and OVRDBF dilemma.

Will,

Well, can you submit Program C so that it runs in batch as its own
job? Or find some way to start it up separately? Is this a non-JDE cl
job stream that you are running? What does JDE support say?

John Dickey
JDE Financial Systems Administrator/Programmer/Analyst
White-Rodgers, Division of Emerson
St. Louis, MO
314-553-3067


_____

From: [email protected] [mailto:[email protected]]
On Behalf Of jdeuser2001
Sent: Monday, July 17, 2006 2:21 PM
To: [email protected]
Subject: Re: RE: Open Query and OVRDBF dilemma.


John,

Indeed. Unfortunately, there is no other logical to use. F4801 physical
is keyed by WADOCO which is the access path that Program C needs. I
suppose I could create another logical file, i.e. F4801LZ, keyed by
WADOCO, and modify program C to use it. Unfortunately, again, program C
is a standard JDE program, used several places, and I am trying to stay
away from modifying it (unless absolutely necessary.) Program C is
P31410.

Is there another way of keeping Access Paths unique?

Thank you for your help!

Will.


_____


The entire <http://www.jdelist.com/ubb/showflat.php?Cat=3D&Board=3D>
JDELIST thread is available for viewing.


Looking for a job? Check out the Job
Opportunites
forum=09

This is the JDELIST World Mailing List.
The instructions on how to unsubscribe from any JDELIST mailing list are
available here <http://www.jdelist.com/unsubscr.shtml> .
JDELIST is not affiliated with JDEdwards(r).

.

To unsubscribe from this list via email, Click <mailto:
[email protected]?Subject=3DUnsubscribe&Body=3DSirs,

Pleas e
remove this address from the JDELIST World Mailing List.

Thank

 

[Hahn_Associates]

Re: RE: Open Query and OVRDBF dilemma.

Use the LF in program A and access it sequentially.

jdeuser2001 <[email protected]> wrote: John,

Indeed. Unfortunately, there is no other logical to use. F4801 physical is keyed by WADOCO which is the access path that Program C needs. I suppose I could create another logical file, i.e. F4801LZ, keyed by WADOCO, and modify program C to use it. Unfortunately, again, program C is a standard JDE program, used several places, and I am trying to stay away from modifying it (unless absolutely necessary.) Program C is P31410.

Is there another way of keeping Access Paths unique?

Thank you for your help!

Will.

 

[mteng]

Re: RE: Open Query and OVRDBF dilemma.

Sounds like program A is a non-jde program, is so you could call QCMDEXC to delete the override before calling program C
Just a thought.

 

[jdeuser2001]

Re: RE: Open Query and OVRDBF dilemma.

We can't delete the override because Program A calls Program C within a loop.

Specifying creation of a logical file instead of an Opnqry may be a possibility . . .

Thank you all for your help and thoughtfull responses!

 

[fshort7]

RE: RE: Open Query and OVRDBF dilemma.

Will,

If you don't mind making a 55 version of the JDE code simply after the OPNQ RY and CALL to process the access path do the following:

DLTOVR filename

CLOF

Then call the last program in the line. It will not see the QPNQRY file i d.

Fred

World 7.3 C10

 

[Hahn_Associates]

Re: RE: Open Query and OVRDBF dilemma.

You can continue to use the OPNQRYF function of the DW in pgm A. Just specify a LF in the DW file selection. Change the OVRDBF to overide the LF than go into pgm a and specify the LF.

jdeuser2001 <[email protected]> wrote: We can't delete the override because Program A calls Program C within a loop.

Specifying creation of a logical file instead of an Opnqry may be a possibility . . .

Thank you all for your help and thoughtfull responses!

 

[jdeuser2001]

Re: RE: Open Query and OVRDBF dilemma.

Thanks guys - all good suggestions! I have tried using Logical File creation in DW and it worked, but was way slowwww - F4801 we're using is humongous, CL was trying to index this logical on the fly each time it ran and it took some time . . .

The solution I finally found is as following (please feel free to point out any flaws in this approach):

1. DW is based on F4801 with OPNQRY option specified.

2. CL performs OVRDBF F4801 to F4801E SHARE (*YES)

3. RPG pgm A opens F4801E for seq. processing

4. RPG pgm A calls other std JDE pgms which open a unique access path to F4801.

P.S. F4801E is a dummy file (i.e. no data just file definition) which contains no records - used for compile purposes only.

Will.