Ignition Reporting <N/A> in Saved PDF: Find the Null Key

The setup: Ignition 8.1.44, a Vision client, and Reporting module 6.1.44. A header line such as Report for Serial Numbers ... date looks correct in the designer. The PDF saved from a button script shows a bold <N/A> printed on top of the date. The same report sent to a printer through .print() on the Report Viewer comes out clean.

Get it running, then fix it properly. Rule out the quick fixes first so you don't lose the shift on them.

Skip These Quick Fixes

These are the usual first moves. None of them removes the cause.

• Nudging text fields apart in the designer. This only moves the overlap. The <N/A> is real content that the report generated. It is not a rendering smear.
• Rewriting the save script. The script only asks the Report Viewer for bytes and writes them to disk. It does not create text, so it cannot add <N/A> to the header.
• Blaming the printer path because it "works". A clean printout does not mean the report is clean. Hidden content can land off-page or be painted over on paper and still show in a PDF.
• Re-running with the same parameters and hoping. If a key resolves to null once, it will resolve to null every time with the same inputs.

Understand Where <N/A> Comes From

The Reporting module prints <N/A> as its default value for a null. Every time you see it, a @key@ reference was evaluated and returned nothing. This happens when:

• the key name does not match any parameter or data source (typo, renamed parameter, deleted query), or
• the key exists but its value is null for this run.

It appears bold and on top of the date because it takes the formatting of the text box or run it lives in. That box sits in the same header area as the date. The usual carriers are:

• An extra line in the header text box that is out of view in the designer. The box is drawn shorter than its content, so the second line never shows while you edit. At render time it paints over the neighbouring field.
• Stray formatting characters after the static text. For example, a trailing return and a leftover @key@ after Report for Serial Numbers.
• An extraneous text field in the table header. This is often a duplicate left behind after copy/paste. It is stacked exactly on the date field.

The difference between print and PDF comes from the output path and the viewer. PDF viewers do not all handle overlapping objects the same way. Some files render correctly in Chrome or Edge but show overlapping objects in Adobe Reader. Also, getBytesPDF() and saveAsPDF() are separate calls on the Report Viewer. Compare both before you decide the content is fine.

Diagnose the Header in This Order

1. Open the saved PDF in Chrome or Edge as well as Adobe Reader. If <N/A> appears only in Adobe, the PDF has overlapping objects. There is still hidden content in the header, but the viewer decides whether you see it.
2. Save through the other call. Run a test button with event.source.parent.getComponent('Report Viewer').saveAsPDF() instead of the getBytesPDF() path. Compare the two files.
3. Select the header text box in the designer and drag it taller. Look for a second line or a @key@ below the visible text. Put the cursor at the end of the static text and press End and arrow down. Any movement means there is hidden content.
4. Check for stacked objects in the table header. Select the date field and move it aside temporarily. If something is still sitting underneath, that is your carrier.
5. Match every @key@ in the header against the Data Keys browser. Any key that is not listed, or is spelled differently, will render as <N/A>.
6. Preview in the designer with the same parameter values the client passes. A key that is populated in preview but null at runtime points to the parameter binding on the Report Viewer, not to the layout.

Fix the Header Properly

1. Delete the hidden line, trailing characters, or duplicate field you found. Don't just resize the box to hide it again.
2. Replace the row of separately aligned text fields with one text field per line. A single text field can hold several formatted runs, so the bold label and the normal-weight date can live in the same box. There are no longer separate objects that can drift onto each other.
3. For spacing inside that one field, use keychain expressions inside the @...@ tokens to pad text programmatically. Don't use spaces or tabs to force alignment. The ReportMill keychain reference covers the available functions.
4. If a key is legitimately null for some runs, fix the source instead. Supply a value from the parameter or query, or handle the null inside the keychain expression. That way the default <N/A> never reaches the page.
5. Keep the save script simple and unchanged while you test, so the layout is the only variable:

viewer = event.source.parent.getComponent('Report Viewer')
pdfBytes = viewer.getBytesPDF()
system.file.writeFile(savePath, pdfBytes)  # savePath comes from your existing logic

Check the Report Viewer scripting function reference for the exact argument options of saveAsPDF() before you swap it into production.

Verify Before You Hand It Back

1. Generate the PDF with the production button. Open it in Adobe Reader and in Chrome or Edge. The header must be identical in both.
2. Print the same report with .print() and hold the paper against the PDF. The content and positions must match.
3. Run it with a parameter set that previously produced a null. Confirm the field shows your handled value, not <N/A>.
4. In the designer, select all in the header band and count the objects. There should be one text field per line and nothing stacked.

Watch for These Repeat Offenders

• Copy/paste duplicates. Pasted fields land exactly on top of the original and are invisible until one of them renders <N/A>.
• Renamed parameters. Renaming a report parameter or data source does not update the @key@ text in existing boxes. Every stale reference becomes <N/A>.
• Text boxes smaller than their content. The designer clips the view, but the renderer does not reliably clip the output.
• Validating on one viewer only. A PDF that looks right in one viewer can overlap in another. Test on the viewer your users actually open.

FAQ