If you put a define in the master and recurse
with the join below then you get

FILE=equipment_functional, SUFFIX=SQLORA, REMARK='Equipment Functional'
SEGNAME=EQUIPMENT_FUNCTIONAL, SEGTYPE=S0, $
  FIELD=EQF_CONTRACT, ALIAS=CONTRACT, USAGE=A5, ACTUAL=A5, $
  FIELD=EQF_MCH_CODE, ALIAS=MCH_CODE, USAGE=A100, ACTUAL=A100, DESCRIPTION='Object ID',TITLE='Object,ID',MISSING=ON, $
$ These defines disabled since they cause problems in recursive joins - issue manually if necessary
$ DEFINE EQF_MCH_KEY/A105 = EDIT(EQUIPMENT_FUNCTIONAL.EQF_CONTRACT,'99999') | EQUIPMENT_FUNCTIONAL.EQF_MCH_CODE ;, TITLE='Equipment,Object,Key', DESCRIPTION='Equipment Object Key', $

This is the error

(FOC104) DEFINE IN MASTER REFERS TO A FIELD OUTSIDE ITS SCOPE: EQF_MCH_KEY
 0 ERROR AT OR NEAR LINE    208  IN PROCEDURE ALLSERVERFOCEXEC *
 (FOC258) FIELDNAME OR COMPUTATIONAL ELEMENT NOT RECOGNIZED:
 EQUIPMENT_FUNCTIONAL.EQF_CONTRACT
 (FOC101) ERROR IN DEFINE IN MASTER FILE: EQUIPMENT_FUNCTIONAL
 

As you can see I tried to qualify the segment and this does not resolve the problem or does it work without.



This works with the define removed from the master so it must be creating the define in the renamed J1 segment and confusing itself

JOIN EQF_CONTRACT AND EQF_SUP_MCH_CODE IN EQUIPMENT_FUNCTIONAL TO EQF_CONTRACT AND EQF_MCH_CODE IN EQUIPMENT_FUNCTIONAL AS J1 
DEFINE FILE equipment_functional 
EQF_MCH_KEY/A105 = EDIT(EQUIPMENT_FUNCTIONAL.EQF_CONTRACT,'99999') | EQUIPMENT_FUNCTIONAL.EQF_MCH_CODE ; 
END 
TABLE FILE equipment_functional 
PRINT *  
END 

So dont use defines in masters that contain hierarchies.

This message has been edited. Last edited by: hammo1j,

John,

I am not surprised: when you have a recursive JOIN, then the DEFINES in the MASTER would be replicated and the lower one would then not point to the segment where it is defined.
You could try to do away with the prefix:

  
DEFINE EQF_MCH_KEY/A105 = EDIT(EQF_CONTRACT,'99999') | EQF_MCH_CODE ;, TITLE='Equipment,Object,Key', DESCRIPTION='Equipment Object Key', $

and see if it helps...

Danny

You are right that the problem is with the defiine replicated in the lower segment, but there is no rule that says a define has to refer to fields in its own segment - I have some in non recursive clusters and they work.

In theory the replicated define should just refer to the parent and not cause a problem.

Taking the prefix off does not resolve the problem but as always thanks for your input.

The cause of the problem is that, for recursive JOINs, WebFOCUS prefixes the fields in the second file with the AS name. So, fields in the joined file become J1EQF_CONTRACT and J1EQF_MCH_CODE. This allows you to reference fields in both segments without ambiguity. Issue the JOIN then CHECK FILE equipment_functional PICT to see this.

The DEFINE in the second, recursed segment fails because it does not reference the renamed fields.

The solution to this is to use TAG in the JOIN:

 JOIN EQF_CONTRACT AND EQF_SUP_MCH_CODE IN EQUIPMENT_FUNCTIONAL TO EQF_CONTRACT AND EQF_MCH_CODE IN EQUIPMENT_FUNCTIONAL TAG XX AS J1 

The TAG value overrides the AS name. You can reference fields in the JOINed segment by prefixing the fields with the tag value, a period, and the fieldname, for example: XX.EQF_CONTRACT.

Issue TABLE FILE filename, then ?F, to see how the fields are renamed.

A more complicated way is to code the cross-reference directly into the Master, where you can rename the fields for the second segment.

Cheers Robert

Using the newer TAG works although I dont agree with your reasoning as to why the join prefix does not work since it is perfectly possible to refer to a field in a define in the master outside its own segment in a cluster.

Never mind TAG works better than AS!

Also you need

SET QUALTITLES=ON

to see the prefix where SET TITLE=OFF unlike AS which appends directly.

This is quite a nice feature in that it does not qualify all titles only enough to disambiguate.