Precisely Speaking
May 21, 2012, 07:57:44 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: So what's news with you?  Tell us about it in "Getting To Know You"!
 
   Home   Help Calendar Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: Using SB.VALIDATE  (Read 6291 times)
Tom Pellitieri
Rock Star
*****
Posts: 171


Tom Pellitieri - Toledo, Ohio


« 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
Rock Star
*****
Posts: 171


Tom Pellitieri - Toledo, Ohio


« 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
Rock Star
*****
Posts: 171


Tom Pellitieri - Toledo, Ohio


« 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



WWW
« 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
Rock Star
*****
Posts: 171


Tom Pellitieri - Toledo, Ohio


« 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



WWW
« 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
Rock Star
*****
Posts: 171


Tom Pellitieri - Toledo, Ohio


« 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



WWW
« 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
Rock Star
*****
Posts: 171


Tom Pellitieri - Toledo, Ohio


« 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



WWW
« 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.
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.7 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!