Report Writer Break Line

[Thomas]

Hi guys, I am the new kid on the block.  Kevin was so kind and open the door for me.

I've been searching this forum for all I could find about break lines and have learned quite a few new and interesting things.  However, for the current situation, which frustrates me to no end, I haven't been able to find anything.  I have a hunch, though, that this has something to do with the @AM as the last key in the select list.

My situation is that I am doing a couple of reports and I am deriving the customer description, for example, by using B.CUST.NUM.  This works fine  for every break line, except the very last customer break line.

The last line shows the Customer Number, but not the Customer Description for this break customer.

I know I could use @SBPARM(17) to derived the description by running a process before break, but that seems to be a very clumsy solution, because I have 5 break fields in this report.

Has anyone seen this before and found an easy workaround for this issue?   

[davisd]

I use the process before break to store the contents of @RECORD and @KEY in other common variables, then put @ORIG.REC and @SBPARM(17) back in @RECORD and @KEY.

This way, you can just use the field names in the break sections instead of using the "B.fieldname" method that only works on the break fields.

In the process after break I move the current values back into @RECORD and @KEY.

[rhettler]

If company number is the first 3 characters of your key then use  @SBPARM(17)[1,3]:B.CUST.NUM as the key to other file. If you use CO.NUM  which get the company from the current key, by the time the report prints the last break the key is empty since there is nothing else to print.

[precisonline]

First, welcome Thomas; glad you're here!

If your report is calling GET.CO to initialize the company number, you can use @PARMS(1)<1> in place of the @SBPARM(17)[1,3] that Rick has shown.  It may also be available as CONO, though I recall that global equate is overridden by a field definition in some files.

The point here is that the B.CUST.NUM is going to be the customer number only.  You need the company number on the front of that to get the description.  Most if not all reports will run for one company only, so if you pull it from the last key (@SBPARM(17)) or from the global equate (@PARMS(1)<1> or CONO),and add it to the customer number, you should have everything you need to read anything from the CUSTOMER file.

[Thomas]

Thanks for the prompt replies davisd, rhettler, and Kevin,

The problem is not with deriving the customer description.  The problem ONLY occurs on the LAST break line.  All other break lines work just fine.

[rhettler]

The problem you have with getting the description on the last break line is because you are likely using CO.NUM in the key to the customer file. CO.NUM works perfectly on a derived field on a detail line but not on a break line for this exact reason. I would expect all other break lines to work and the last break line would not. Use @SBPARM(17)[1,3] instead of CO.NUM and your problem should be solved.

[Thomas]

rhettler, actually, I am using @PARMS(1)<1> to get the company number.

[rhettler]

I would try to create a field on the break line to see the value of what you are using as the key to the other file. I guess in your case  the derived value of the report field would be @PARMS(1)<1>:B.CUST.NUM

[Thomas]

rhettler, actually, I am using @PARMS(1)<1> to get the company number.

That is exactly what I am doing.  It looks like ALL the B. fields, B.CUST.SLSM.MGR, B.CUST.SLSM.NUM, B.CUST.NUM, B.PORTFOLIO.JSI, and B.PLINE.NUM, get trashed.  They do show on the report, but then, when it comes to the derivation like (F("CATEGORY",CO.NUM : B.PLINE.NUM)<1>), they are trash and thus showing a blank decription.

But this only happens on the LAST break line.  All OTHER ONES are just fine.

[precisonline]

Replace CO.NUM with @PARMS(1)<1> in those derivations and see if that helps?

[Thomas]

Replace CO.NUM with @PARMS(1)<1> in those derivations and see if that helps?

Why, oh why did I not listen sooner.  When I set up new derived dictionary items, I always use @PARMS(1)<1>, but here I didn't.  I thought I had used @PARMS(1)<1>, but apparenly, I didn't.  When I did the change, it worked.  Thanks to all of you for your help and suggestions.

I wonder what happens to CO.NUM, though.

[precisonline]

CO.NUM is derived off of @KEY and when the report writer gets to the end of the list @KEY = an attribute mark.  Keep in mind that for a break to occur SB+ has to read the next record beyond the break.  So at the end of the report CO.NUM is an attribute mark not the 001 as it was for the previous record.

[Thomas]

Kevin, you are absolutely correct.  Looking CO.NUM in the field definitions, we see a derivation like this (<0>[1,3]).

It would probably be a lot easier to replaced the derivation with @PARMS(1)<1> in the field definitions, wouldn't it?  Or is there a draw back to this, that I can't think of at the moment?

[precisonline]

Because the records in any given file in Prelude can have a company number on the front of the key, CO.NUM is the company number specifically for the current record.  CONO, i.e. @PARMS(1)<1>, however is the "current" company number in effect for a screen or report.  So they're different things really.  CONO is transient and is just a value in memory, CO.NUM, however, is persistent.

So while it may seem confusing, it's actually a good thing that we have both especially if there could be more than one company in play.  For reporting purposes, as long as you're only reporting for one company at a time, CONO is probably best/easiest.  If you had to do something that spanned multiple companies, however, then CO.NUM might be the better choice.