Confused on Processing Option ID - XE SP23

[Zoltan_Gyimesi]

Hi JDEList,

I have a large and complicate interactive application (wit 33 Forms on the current system) which is continously "under construction" since more years ago, adding new features, functionalities and fitting it to the different partners' requirements. Its Processing Option is also large (12 Tab Page, 50+ ProcOpts) and is continouly extended with new fields.

I recently noticed, when I print the PO template from the Processing Option Design Aid, the in the last column of the report, the ID Items are not unique

This occures, when I used the same DD Item more times on different Tab Pages (of course, with unique PO field name).

On the other hand, if I explore the spec of this PO template from F98743 DSTMPL.DDB spec file, opening it with "Open RDB...", then I see unique values in the idItem fields.

Now I get a bit confused and courious, and this scenario opened several question for me, including the following:

#1. Can it cause any problem, issue somewhere in development, including special tasks?
#2. Which ID to pass to the Get/Update Processing Option BSFNs (B9090001)?
#2. Can I somehow see the real ID in Processing Option Design Aid?
...etc.

Any input to this issue will be greatly appreciated.

As far as I remember, there were some posts on JDEList related to PO field unquities, but I can not recall, how can I find it, so if somebody can point me to that thread, then it will be also appreciated.

By the way, a bit strange, that szPOOptionID in the DSTR of B9090001 BSFNs is STRING and it is 36 char LONG

Thanks in advance & Regards,

Zoltán

 

[Zoltan_Gyimesi]

FYI,

You can open and explore remote and local TAM/SPEC file with UTB with the following jde.ini entry:

[INTERACTIVE RUNTIME]
TAMMenus=Show

(at least on XE SP23)

You will have 3 additional "Openxxx" selection under the File menu of UTB. Have a fun to play with them

Regards,

Zoltán

 

[Adrian_Chimirel]

Servus Zoldy,
Using the same DD item on a Proc Opts template is risky. I stopped doing it after reading the same posts you mentioned on JDEList.
I would look into the Downlods section for them.
PS 33 forms, 12 tabs, 50 proc opts - wow! this grew a bit too large to maintain, not to say about development.
Sorry I can't help (my personal approach is to limit apps/proc opts to 5 forms / 5 tabs / 25 proc opts tops).

 

[BOster]

[ QUOTE ]
Servus Zoldy,
Using the same DD item on a Proc Opts template is risky.

[/ QUOTE ]

Out of curisoity, why?

 

[Adrian_Chimirel]

You just had Zoltan's confirmation; somehow the Proc Options ID do not advance, thus being ignored at runtime

Why this happens ... ask Denver

 

[BOster]

Well, I have done this quite a bit w/o any *known* problems. He also stated in his post that the spec files DO have unique IDs. So... is it really a problem.

 

[jitender]

Hi Zoltan

I have to add something to it.

I read it somewhere may be on jdelist that if we are using the same DD on the Processing option than JDE sometimes not able to idendify the Uniqueness of the DD used.

Foreg:

i used DGJ data item on the PO template.as Current_DGJ

and i used it again on the same tab or in the processing option after making a copy of it and changing the name to Future_DGJ.

Now problem appreas when we use this PO in the code itself.
JDE is not able to Get the values of the second DGJ(Future_DGJ) Data item. as they have same DD (DGJ).

and if JDE is configured with UNIX server ,May be i am wrong than its not able to identify the Uniqueness of the second DD.

I faced this issue when i was working for one of my Client.
i was able to use it locally ,but when i was using it on the server i encounter this Problem.


So Best way is to take a Unique DD item on a Processing option.

Regards
Jitender

 

[jitender]

Hi Zoltan

Please refer to #64206 post in Tips and Traps.

Regards
Jitender

 

[Zoltan_Gyimesi]

Hi Ady, Brian, Jitender,

As far as I remember, vanilla APPLs/UBEs PO templates also use same DD item more times, am I right.

I had never problem using same DD Item more times on PO templates.
Sometimes trivial to use the same DD Item more times, e.g.:
- to list more DocType to process
- in my case to list Default Statuses (custom DD) for different type of records (for Technology Items)
- etc.

About the large APPL, etc.:
When I started to develop this, I had not see, where will it grow to.
cca 10 of the forms are message and dummy transaction frame forms, and they really should not required to be in the same APPL, but the other forms are dealing with the same Processing Option, and this is the reason to keep them in the same APPL.

The mentioned APPL is one of the core APPL of a cutom modul, which pupose is:
Quote Handling, Budget Planning, Project Managemet with many-many functionality and join to other vanilla moduls (Purchasing, Priceing, Stock/Inventory Handling, etc.)
This modul currently has:
157 Objects (including 30 Tables)
233 Data Items
57 Messages

Regards,

Zoltán

 

[JMast]

Jitender,

I have used the same DD on Processing Options quite often and never had a problem. In fact, on one tab of a PO template for a UBE, I have TRDJ eight times.

Your quote: "after making a copy of it ", raised this question for me. Is the trouble in copying a field on the template to create a new field?

I have always just dragged the DD over again from the DD Browser to create a new field. Maybe this causes the RDA to treat it as a new object and assign a unique ID and copying does not.

Unfortunately, my schedule is loaded and I don't have time to experiment right now.

Jer

 

[BOster]

Ok I think I figured out what the "trap" is when using multiple DD items, but it is easily avoided. I created a new PO template and added the DD item VERS twice, however, I did NOT change the default parameter name so I end up with two szVersion params. When I create a type definition, this is what I get:

typedef struct tagDST59TST08
{
char szVersion[11];
char szVersion[11];
} DST59TST08, *LPDST59TST08;

#define IDERRszVersion_1 1L
#define IDERRszVersion_2 2L


Since I almost always rename my parameters, I never have ran into the problem.

 

[Zoltan_Gyimesi]

Hi Brian,

Thanks for the information.
I always use UNIQUE Processing Option names inside a PO template, but frequently use same DD Item on a PO template.

Do you think, the problem occurs only, when the PO names are not unique?

By the way, what ID Item value do you see on the printed PO and in the RDB spec?

Would be great, if somebody has enough time to elaborate this issue in detail:
- producing PO where the printed PO shows non-unique ID Item
- checking it in APPL, UBE - the second locally and on server
- checking Get/Update PO Values BSFN whith the printed ID Item value and with the other from RDB.

If somebody will do that, then I will greatly appreciatte it - and I suppose, not only me.

Regards,

Zoltán

 

[BOster]

Here is my guess.

If you use the same DD item multiple times and dont change the name it is probably only an issue if you use the template in a BSFN (the BSFN simply won't compile). It is probably not an issue in ER code since ER code really uses the underlying ID of the parameter, not the parameter name. However, inside of the ER editor it could be confusing because you would have multiple PO variables w/ the same name. Of course, you can also have multiple FC variables with the same name as well... As far as showing the wrong ID in the template design aid I suspect it is simply a display bug in the DA and probably doesn't really cause any other problems... again, just a guess.

 

[Zoltan_Gyimesi]

Hi Brian,

I agree - OW is based on the hidden internal IDs.

#1. I always wondered, why does not Developer Tools pop up an error, if I try to assign a non-unique name for:
- FC, GC in an APPL
- RV in an UBE
- member name in a ProcOpt
while it do, when I try it for:
- any ER variable with the same scope
- in a DSTR for a BSFN
...etc.

So, (by my humble opinion / IMHO) I it is the developer task (or fault), to assign unique name - of course - by other practical reason too.

The other behaviours of SP/TS levels are still open - why do not use the same DD Item on a PO template. WHY DO NOT, if I assign a UNIQUE PO member name to it??? WHY to create a new DD Item, when I want to use same type of user input more times on a PO template?

At last, but not least - Thanks all of Listers' inputs.

I hope, this issue (thread) will be advanced with more usefull parctices and inforamation.

Regards,

Zoltán