(Un) Learning by (bad) example...

[Tom Pellitieri]

I sure I'm not alone when I say that I learned a lot about how to program in SB+ by reviewing code written by others.  When I first started learning this 15 years ago, there was not a lot of introductory training material available, and of course our company relied on our solution provider for the necessary training.

The unfortunate part of this I've discovered over time is that our solution provider had not really used SB+ to its full potential.  Therefore, when I looked at examples at how to do things, I wasn't always seeing the best way to do it, or in some cases even a half-way decent way to do it.

Over the years, I've been trying to "unlearn" some of these bad habits by taking the time to learn more about the SB+ tools that I don't use much.  There have been times that I find something and effectively kick myself in the head for not having learned about it earlier.

A prime example of an underused SB+ tool recently came to my attention, quite by accident:  the File Update Process Definition (/PD.F).  At this point, I have two such processes in my xxPROCESS file, and both were written by me this week.

A File Update Process is designed primarily to be called from the Process After Update slot in /SD.  It simplifies the update of additional files based on data from the active file.  In the various definition screens, you can specify the field names to update in the target file, and update values using field names from the source file.

Typically in the past, I've done this with a paragraph, similar to this:

@RTN.FLAG = 0
READU @OTHER.REC FROM "FILE","ALTKEY"
IF @RTN.FLAG = 0 THEN
   @OTHER.REC<1> = @RECORD<2>
   WRITE @OTHER.REC ON "FILE","ALTKEY"
ELSE
   DISP 3,"ALTKEY not found on FILE!"
END
RELEASE "FILE","ALTKEY"

All of your standard arithmetic operators are available in /PD.F, but the ones that surprised me today were the Multi-Value update options.  In File Update, you can specify to Insert a Multi-Value in a field, including sort order, and avoid duplicate values if necessary!  (Check the F1/F3 options on the Operator field for more info).

I can't begin to count the number of BASIC subroutines I've written with variations of the following code, which can be handled by this type of process:

LOCATE NEWVAL IN RECORD<1> SETTING SPOT ELSE
    RECORD = INSERT(RECORD,1,SPOT;NEWVAL)
END

Both of the tasks I've outlined above are SO much easier with /PD.F.

However, there is one thing I haven't figured out...

There are times I want to insert a new MV if necessary, then update corresponding MV's in other attributes.  In BASIC, I would write:

LOCATE NEWVAL IN RECORD<1> SETTING SPOT ELSE
    RECORD = INSERT(RECORD,1,SPOT;NEWVAL)
    RECORD = INSERT(RECORD,2,SPOT;0)
    RECORD = INSERT(RECORD,3,SPOT;0)
END
RECORD<2,SPOT> = RECORD<2,SPOT> + VAL2
RECORD<3,SPOT> = RECORD<3,SPOT> + VAL3

Does anyone have an idea how to do this using /PD.F?

--Tom

[JOHNR]

I think you need the "" (ditto ?) entry.

From the F1 help ...
                                                                         
"" will use the same position as the previous multi-valued field.         

[nmorgan]

Yep, we learned from the same namless solution provider!  But to be fair, they didn't start from scratch developing in SB+.  Rather, they took an old and lumpy barefoot Pick application and hurriedly stuffed it into a spiffy new set of SB+ clothes.  A classic triumph of form over function.

What is harder to understand is their love of the inline process, i.e.
P:(DO SOMETHING HORRIBLY LONG UGLY AND OBTUSE HERE REGARDLESS OF THE FACT YOU WILL EVER BE ABLE TO SEE IT ALL AT ONE TIME TO FIGURE OUT WHAT THE HECK IT IS DOING)
They still do this, even in newer code.

[Tom Pellitieri]

JohnR,

Thanks for the suggestion, but the "ditto" entry only works correctly if the value is already in the list.  If you add a multi-value and use the "ditto", the additional values are not inserted.  Consider this sample, where semi-colons represent value marks:

1: BLUE;RED;YELLOW
2: 4;3;6

If I try to add the value "GREEN" to attribute 1, the value position will be set to 2.  The "ditto" command would then work on the second multi-value in attribute 2 (i.e., the 3) instead of inserting a new value before it.  If I choose to insert a value, a new value is entered even when I match an existing value in Attribute 1. (sigh)

--Tom

[JOHNR]

It's been a while since I used these things.
Many clients are extremely nervous of some of the more "exotic" features of SB+ <sigh> so I do not get the practice I would like.

but

if I remember correctly you use a combination of "" ditto
with IAR(N as the operator.

So the <1> just gets IAR(N and <2> just gets "" - maybe with the I(nsert) operator.

I'm sure that used to work as you describe - I could be wrong - would not be the first time.

Now I will have to try and test it.

Cheers


JR