Is it possible to have sub-value marks in data be turned into line feeds in Run_Report?

rogercurtishall

This is for an OI 8.0.1 app. I have the following statement which I am passing to Run_Report.

LIST TABLE BIG04 COLHEAD "PO#" QTY_IT1 COLHEAD "qty" LOTNUM_IT1 COLHEAD "Lot#" EXPDATE_IT1 COLHEAD "Exp Date" WITH BIG04 = "01011011101" ID-SUPP BY BIG04

The data I want to make into line feeds are subvalue marks in a couple of the columns.

Thanks in advance.

DonBakke

No. You could create calculated columns to massage each data column value so they will report as you wish.

rogercurtishall

Hi Don.
I am trying this now and it is working, except for one anomaly. I have 3 data columns to which I want to apply this. So I set up 3 calculated columns, one for each of the data ones. The first two work for my test data, with the first value having 3 subvalues. The report is dropping the third subvalue in the first value for the third symbolic, which has this logic:

FLD = {EXPDATE_IT1}
swap @svm With \0D0A\ In FLD
@ANS = FLD

The other two symbolics have the same logic, with just the FLD value being different. As far as I can see, the data in that third field matches the others as far as the subvalue & value marks.

Any thoughts on this?
Thanks.
Roger

DonBakke

Before digging deeper into this, have you tried just converting @SVM to @VM and then setting the columns to be MultiValued? I think that will produce better results in R/List (Run_Report).

rogercurtishall

It solves the problem of the missing data, but it creates a worse problem. There is another value marked field in my report, and using the @vm causes the misalignment of the value marked data. With the CRLF swap, the value marked fields for both the ones with subvalues and the one without stay aligned.

DonBakke

I'm at a disadvantage because I don't know how the data is stored in its natural state nor do I know what these fields represent. For example, why were @SVMs used in the first place? Ordinarily I would expect an @SVM to only be used when the field is already using @VMs.

If, perchance, the @SVMs are quasi-linefeeds, then perhaps swapping them with @TM might work better. Make sure to change the justification to Test as well.

rogercurtishall

I tried using @TM instead but they didn't work at all. The data involved has both value & subvalue marks. Here is a screen shot of the actual values from the SRP Editor. Does that help?

BarryStevens

try converting @vm to "|" to at least see what data is being produced

FLD = {EXPDATE_IT1}
swap @svm With \0D0A\ In FLD
convert @vm to '|' In FLD
@ANS = FLD

DonBakke

Roger - That does help somewhat. Which of these columns are associated? Which ones are unassociated? Finally, exactly how do you want this to look in the Run_Report output? Are you trying to flatten out all @SVMs? Perhaps if you mocked up the layout in Excel that would help me better understand what you are aiming for and what might the issue.

BarryStevens

Don, you are onto something there.
IMHO the @vm are associated to each @vm in fld1 (Is that amv)
Therefore this would make more sence

FLD = {EXPDATE_IT1}
convert @svm to '|' In FLD
@ANS = FLD

rogercurtishall

Hi Barry. Using the vertical bar doesn't work. All the data shows on the same line.

Don, check out the attached report output. The first record shows what I want, except there should be another Expdate value following the qty 6 and second lot# 234. This output comes with my original logic of swapping @svm to crlf.

DonBakke

Why does the original LIST statement filter BIG04 to a specific value and also sort by that column? Is BIG04 a single value or multivalue column

rogercurtishall

BIG04 is a single value. The other columns are all multivalue with both value & subvalue marks.

DonBakke

Roger - Very good. I just wanted to rule out any interference from the "BY" keyword. If the column that is being sorted is multivalued, it could impact how the entire report is rendered. That said, I would remove "BY BIG04" since it serves no purpose and possibly slows down the processing of the report.

I now suspect the reason why the final "20250522" is dropping off is because the dictionary column width value isn't big enough to store all that text. My theory is that when you use the CRLF delimiter, OI still sees all of the result as a single string. This is why I was suggesting using @VM instead so OI would look at each delimited value separately.

Can you see if adding width to the column definition resolves the problem? I'm not suggesting this is a perfect solution, but it would confirm my theory and give us more information that we can use to create a better solution.

rogercurtishall

Good idea Don. Increasing the column display size did the trick. Thanks!

DonBakke

Roger - I'm glad that worked, but that is likely not a long term solution unless you set the width to be so big that it will handle any number of @SVM items.