Histill new to Webfocus so be indulgent please. In my proce...

[David McKinney]

Histill new to Webfocus so be indulgent please.

In my procedure, I create a hold table which I explicitly name (ON TABLE HOLD AS MYHOLDTABLE FORMAT FOCUS)

I subsequently reference this HOLD table, as part of a where clause

WHERE MYCODE EQ &PromptForCode.(OR(FIND FLDLOOKUP, FLDDISPLAY IN MYHOLDTABLE|SORT=ASCENDING)).Choose:.;

What I observe is that the code in the WHERE is not referencing the version of the table I created further up. It appears to be finding an old version on file somewhere.

And if I add a new field to my HOLD Table, it is not recognised in the WHERE.

As I will reference several hold tables, I think I need to name them individually, but do I need to first delete any straggling versions before creating a new version

I also observe that if I rename my hold table, and run the whole script, the WHERE doesnt find the table I just created. I have to instead isolate the code which creates the HOLD table, and run it separately. I can then run the whole script and it will find the table I created.

In case you are wondering, between the 2 sections of script (creation of hold, referencing of hold) there is a -RUN

What Im thinking is that my hold table is only ever created when its run in a script of its own

[Martin Yergeau]

Maybe it has changed, but I never been able to create a selection list (your &PromptForCode selection on MYHOLDTABLE) from a HOLD file created at a previous step in the same process.

Look like WF cannot find the data in that case.

I assume that a &Prompt is performed by the RS before anything else like a pre-sub-process.

I dont know all your spec, but if you can, take out the section where you are creating your MYHOLDTABLE to be in its own fex and schedule it overnight.

That way your data will exist before your WHERE MYCODE EQ &Prompt and everything should work.

[Alban Hertroys]

If you create a HOLD file without specifying a location to hold it to, you create a temporary HOLD file that automatically gets removed at the end of the fex. That does not work for your case, since the autoprompt facility that would build you your selection prompt gets run separately, without actually running the code and hence the file does not exist at that time.

In your case there is apparently a file of the same name somewhere else in the APP PATH that gets found and used instead.

To solve this, either:

 

HOLD the file in the FOCCACHE to store it in a user-specific session (which gets cleared after ~20 minutes by default), or

write it to a specific APP directory to store it permanently and for all users.

[Steven Hall]

You cannot create a hold file and then reference it using a dynamic autoprompt FIND in the same procedure. The reason is the order in which the fex is processed.

 

Before anything is ran on a fex, WF looks for unresolved parameters and will autoprompt any that it cannot resolve.

Dialogue Manger commands

Table requests

 

So, It is trying to look for the hold file in step 1 before it is even created in step 3.

[David McKinney]

Thanks, all, for these valuable insights. I wouldnt guessed that the code wouldnt be executed in the order its written in. Especially as I thought that the -RUN command would have ensured that the first batch was executed first. see the reply from Ingas here

[David McKinney]

Hi Steven,

Thats a clear explanation, but what it suggests that if I ran the script twice, it would work the second time. (My hold tables would be created as the last step of the first run, and therefore present for the second run.) However thats not the case

Is it perhaps because the first step fails Does it never reach the 3rd step for that reason

I dont suppose I could just reference the prompt variable in a WHERE when creating the hold table (but before the prompt) to change the order of execution

Just trying to fully understand what is going on.

Many thanks,

David.

[Martin Yergeau]

David,

If you hold it in memory, which is probably the case, even running twice wont make it run.

Instead of running twice the same fex as I suggest previously, if you can because I dont know what is the spec for the MYHOLDTABLE, run it overnight and hold it in a app folder.

The file will then be available for the autoprompt FIND feature.

However, this will create one file that will be used by everyone.

[David McKinney]

Hi Martin,

From what I can see, my hold tables are persisted to a folder called output, so not held in memory.

But I will probably schedule their creation as you suggest.

Its a little annoying though as (in another use case) I was planning to use hold tables as subqueries filtering historical data on a date entered by the user at runtime. Obviously the scheduling approach wont work for me in that case.

[Martin Yergeau]

david.mckinney:

 

I was planning to use hold tables as subqueries filtering historical data on a date entered by the user at runtime

 

 

This is possible, but not for then be used as input data for an autoprompt FIND feature.

HOLD files are used widely across WF programming based on user selection at run time

[David Beagan]

david.mckinney:

 

Its a little annoying though as (in another use case) I was planning to use hold tables as subqueries filtering historical data on a date entered by the user at runtime.

 

 

This sounds like a use case for chaining. Chaining lets you link input controls so that a user selection in one control (e.g. date) limits or filters the available items in another control.

There is an example that you can run in this post: Chain Controls

[David McKinney]

Hi DavidI dont think I need any chaining here, but Im glad I now know how, should I require it. Many thanks.