|
Tom Pellitieri
|
 |
« on: September 20, 2007, 09:05:00 AM » |
|
I'm trying to find documentation on SB.VALIDATE. Prelude's software uses this in their /GRIM process, which allows for validation on their data driven report parameters. Unfortunately, it doesn't seem to work correctly when the validation code is of the form:
E:TABLE('code-table') > ''{[E42]}
Any thoughts??
--Tom
|
|
|
|
|
Logged
|
|
|
|
|
Tom Pellitieri
|
 |
« Reply #1 on: September 20, 2007, 10:34:54 AM » |
|
I found a work-around, but I still don't know why the original didn't work.
Instead of using the E: syntax, I created this generic validation process in Process Defn - Validation (/PD.V):
Process Name CEI.GRIM.TABLE Description GRIM Table Validation Dict File Name Validation Code E:TABLE(@PARAM) > ''{[E42]}
I am now using
C:CEI.GRIM.TABLE,code-table
for the validation code. This passes through the call to SB.VALIDATE without problems.
Thanks for listening...
--Tom Pellitieri
|
|
|
|
|
Logged
|
|
|
|
|
Tom Pellitieri
|
 |
« Reply #2 on: September 21, 2007, 05:37:23 AM » |
|
It turns out I wasn't finished...
Since my report allows for multiple values to be selected, I had to set up a multi-value variation of the validation process. Here's the paragraph I wrote to handle it.
Process Name CEI.MV.TABLE.VAL Paragraph Lines LOCAL TABLE.NAME,IDX,MAX.IDX,ERR.MSG,HOLD.VAL,TMP,ERR TABLE.NAME = @PARAM HOLD.VAL = @VALUE READV ERR.MSG FROM "DMCONT","ERROR",42 TMP = REPL(" ",@AM,HOLD.VAL) MAX.IDX = DCOUNT(TMP,@AM) ERR = 0 FOR IDX = 1 TO MAX.IDX @VALUE = TMP<IDX> IF TABLE(TABLE.NAME) = "" THEN ERR = 1 DISP 3,'"':@VALUE:'" - ':ERR.MSG END NEXT IDX @VALUE = HOLD.VAL @RTN.FLAG = ERR
This uses the same error message ([E42] = DMCONT ERRORS <42>) but prepends the invalid value(s). This validation is invoked using
C:CEI.MV.TABLE.VAL,code-table
I hope others find this useful!
--Tom Pellitieri
|
|
|
|
|
Logged
|
|
|
|
precisonline
President/Chief Technologist
Administrator
Rock Star
    
Posts: 1532
|
 |
« Reply #3 on: September 21, 2007, 10:15:52 PM » |
|
I'm confused on a couple of different levels. First, I'll have to check it out but I'm sure that I've probably tried the E:TABLE(..) thing in a /URM validation. Although... usually I use a process called VAL.TABLE which is a /PD.P like this:
IF TABLE(@PARAM) = '' THEN ERROR '[E42]' EXIT 1 END
Now, I don't recall if I created this as a result of the E: thing not working, but no matter. But the multiple entry thing really has me scratching my head. This is called from the URM? And do you have the "multiple entries" set to "Y" for that prompt? I've never had to do anything special for multiple entries as long as this flag is set.
|
|
|
|
|
Logged
|
-Kevin Accidents "happen"; success, however, is planned and executed.
|
|
|
|
Tom Pellitieri
|
 |
« Reply #4 on: September 24, 2007, 06:02:45 AM » |
|
Kevin, I think your /PD.P VAL.TABLE is equivalent to my /PD.V CEI.GRIM.TABLE, just two different SB+ tools.
I wrote some test programs, and the problem seems to be with the call to SB.VALIDATE. My paragraph used the following:
@VALUE = "X" DISP 3,@VALUE:" =[":TABLE("code-table"):"]" CALL SB.VALIDATE("E:TABLE('code-table') > ''{[E42]}")
This test did not complain like it should when @VALUE was set to an invalid table entry.
I can't find any documentation on this subroutine call, so I think it's an SB+ problem. The object code is cataloged under ...SB538....
As to the multi-value problem - In the Intuitive help, I'm using a SSELECT with parameters (WM, which returns multiple selected values delimited by spaces. The validation treats "A B" as a single value, instead of two separate values. If I type "A,B", it correctly validates the two values without the kludge, but since we encourage people to use F3, I had to add the kludge to get space delimiters to work correctly as well.
--Tom
|
|
|
|
|
Logged
|
|
|
|
precisonline
President/Chief Technologist
Administrator
Rock Star
    
Posts: 1532
|
 |
« Reply #5 on: September 24, 2007, 06:11:39 AM » |
|
Understood. I don't know anything about SB.VALIDATE. It's probably the same as prepending a V: on the front of a validation code and doing an inline validation. (Just guessing.)
Just wondering: Is there a reason why you don't want the multiple F3 selection to return the selected values with a comma delimiter?
|
|
|
|
|
Logged
|
-Kevin Accidents "happen"; success, however, is planned and executed.
|
|
|
|
Tom Pellitieri
|
 |
« Reply #6 on: September 24, 2007, 06:47:22 AM » |
|
I would be extremely happy if the multiple F3 selection returned a comma delimited list. However, the "automatic" intuitive help for Code Tables provides the following:
S:SSELECT DEVDEFN 'code-table' BY-EXP TABLE.CODE TABLE.CODE TABLE.DESC USING DMCONT (W
I found (by accident!) that adding M allowed for multiple selections. I haven't found out how to get a comma delimited list from this SSELECT in UniData. (Of course, I'm not certain I want to try to find all of my existing Selection processes which return space delimited lists, either!)
--Tom
|
|
|
|
|
Logged
|
|
|
|
precisonline
President/Chief Technologist
Administrator
Rock Star
    
Posts: 1532
|
 |
« Reply #7 on: September 24, 2007, 07:04:23 AM » |
|
Change the options to (WC and you should be able to return a comma-delimited list of multiple options. Both C and M allow for multiple options, M returns them with spaces, C returns them with commas. (See /PD.S, Options prompt, F3 for a list of the other options that can follow the open paren.
It's also possible to reconstruct this S: thing in a "normal" /PD.S so that SB+ doesn't have to parse it each time. The Dict File Name is DMCONT, the data file name is DEVDEFN, selection criteria is '(@PARAM)', sort fields is TABLE.CODE, display fields is TABLE.CODE TABLE.DESC, and the options is whatever you need to return the right values (but minimally W or G). I have a process called SEL.TABLE that looks like this, and a separate SEL.TABLE.MV that selects and returns multiple values in @VALUE (using WMV options). Then I use a couple of paragraph filters to convert the results to quoted, csv, tsv, or whatever format the application might need.
Hope this helps!
|
|
|
|
|
Logged
|
-Kevin Accidents "happen"; success, however, is planned and executed.
|
|
|
|
Tom Pellitieri
|
 |
« Reply #8 on: September 24, 2007, 07:38:22 AM » |
|
Thanks for the suggestions!
Too bad SB+ doesn't use a similar method when you choose "Table Conversion" from F3 on the conversion code in /FD...
--Tom
|
|
|
|
|
Logged
|
|
|
|
precisonline
President/Chief Technologist
Administrator
Rock Star
    
Posts: 1532
|
 |
« Reply #9 on: September 24, 2007, 07:47:05 AM » |
|
I couldn't agree more! Certainly the way they do Code Table selections is a bit cumbersome, but the way they do accumulators as well as templates in /SD is just down right ridiculous. Fortunately, this stuff is easy to work around.
|
|
|
|
|
Logged
|
-Kevin Accidents "happen"; success, however, is planned and executed.
|
|
|
|