Passed parameters and selection sets

[Nancy Palmquist]

Ray Scheel wrote:
> I was trying to modify a selection (called from a php-built web form /
> command line) that currently selects the desired unit to also be able to
> select all a defined regional grouping based on the contents of a passed
> parameter.  Line "a" works fine, field 5:unitcd(2,*), is correctly
> compared to the contents of @pm.  Where I ran into trouble was when
> trying to add logic to catch the codes for the larger groupings.
> 
> I would enter and save a selection set like this:
> a      |  5  | unitcd ; unit code      eqf|   @pm|
> b      |  @pm| Parameter               eq |   _North
> |
> c      |  @pm| Parameter               eq |   _South
> |
> Selector Sentence:
> a or (b and north) or (c and south)
> 
> but when I came back to it, what showed up was this:
> a      |  5  | unitcd ; unit code      eqf|   @pm|
> b      |  @pm| Parameter               eq |   _|
> c      |  @pm| Parameter               eq |   _|
> Selector Sentence:
> a or (b and north) or (c and south)

First if you are assigning the value with -r on a command line, you can 
use that information in the processing and remove or select as required.

On this selection table, I see no group called north or south so your 
selector sentence is not going to work.

How can the unit code be the same thing as the north/south thing?



> 
> Note the stripping down of the "Value" column to one character.
> 
> I had identical results when using @pw- at pz and when trying "co" instead
> of "eq". Behavior for passed parameters verified on linux versions of
> both 5.0.11aR4 and 5.0.14R4.  The behavior did not carry over when
> trying a few other system maintained fields, it apparently only impacts
> passed parameters.
> 
> I'm going to work around this by selecting all records in the selection
> set when I've got a leading "_" in the unitcd and will instead drop the
> unwanted units in sort/selection processing (referring back the
> selection set "north", "south", etc).
> 
> Has anyone else run into this?  Is there an unadvertised fix or setting
> to change this behavior, or documentation that their use in selection
> sets isn't supported or is (sometimes) limited to the first character?
> Should I just give up on using passed parameters for much of anything in
> selection processing since I keep tripping over significant bugs (e.g.
> the incompatibility with index scan I discovered about a year ago)?
> Surely I'm not the only person trying to use command line parameters in
> selection sets, am I?  I'm getting tired of getting well into a project
> and then having to stop to identify an issue or undocumented limitations
> and then come up with a workaround to compensate.
> 

Just create a scan/select table, pick up the values of @pm, @py, @pw 
etc. and select in that method.  Using a selection table in this way is 
an unconventional solution to this problem.  I am not sure, but I have 
never seen anyone try to do it just that way.

/fp/dreport filename -f something -v selv -r "_North"
───────────────────────────────────
   1  -------   -   -   -   -   -
testa  ◄ If: @pm eq 5	'run with -v from command
        Then:
   2  -------   -   -   -   -   -
north  ◄ If: @pm eq "_North"
        Then:
   3  -------   -   -   -   -   -
south  ◄ If: @pm eq "_South"
        Then:
   4  -------   -   -   -   -   -
        ◄ If: 'decide what you want
        Then: goto pickit
   5  -------   -   -   -   -   -
        ◄ If:
        Then: end
   6  -------   -   -   -   -   -
pickit ◄ If:
        Then: select;end



-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com