David McKinney Posted February 22, 2021 Share Posted February 22, 2021 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 Link to comment Share on other sites More sharing options...
Martin Yergeau Posted February 22, 2021 Share Posted February 22, 2021 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. Link to comment Share on other sites More sharing options...
Alban Hertroys Posted February 22, 2021 Share Posted February 22, 2021 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. Link to comment Share on other sites More sharing options...
Steven Hall Posted February 22, 2021 Share Posted February 22, 2021 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. Link to comment Share on other sites More sharing options...
David McKinney Posted February 23, 2021 Author Share Posted February 23, 2021 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 Link to comment Share on other sites More sharing options...
David McKinney Posted February 23, 2021 Author Share Posted February 23, 2021 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. Link to comment Share on other sites More sharing options...
Martin Yergeau Posted February 23, 2021 Share Posted February 23, 2021 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. Link to comment Share on other sites More sharing options...
David McKinney Posted February 23, 2021 Author Share Posted February 23, 2021 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. Link to comment Share on other sites More sharing options...
Martin Yergeau Posted February 23, 2021 Share Posted February 23, 2021 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 Link to comment Share on other sites More sharing options...
David Beagan Posted February 23, 2021 Share Posted February 23, 2021 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 Link to comment Share on other sites More sharing options...
David McKinney Posted February 24, 2021 Author Share Posted February 24, 2021 Hi DavidI dont think I need any chaining here, but Im glad I now know how, should I require it. Many thanks. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now