Oh wait, no, I’d already changed that, and it’s still throwing the same error?
Can you just put this in that textbox? I have a feeling that it’s blank =Fields!PONum.Value
Does Fields!PONum.Value return a value?
If you set the textbox value expression to = Fields!PONum.Value , does anything show up? The reason I would like to try to put this in that place is to re-set the PO number in the function so that the right one shows up in the header. I think for some reason it is losing the value for that particular po, but I could be wrong.
The other thing that comes to mind is the dataset, is there something wrong with the dataset.
In short, even if you set the value of that textbox to code.SetVarPONum(123456), the number 123456 should show up on the top, but the report might not run because that is used elsewhere to relate other data and what not. I hope I am explaining this somewhat clearly.
Sorry for the wait. It does not return anything, no.
It’s interesting, because the PONum is only wrong on page 2 of some of them, but all the page 1’s are correct. So if I can find where the page 2 PONum is getting set, that’s the problem. I work with reports a lot, but I never have to mess with the code, so I am pretty unfamiliar with what can be done where in SSRS. Frustrating. I so appreciate all your help, Utah.
Erin, almost the same exact thing happened to me with the AR Invoice form a while back. Base form worked but somehow my custom version did not.
Batch printing SSRS reports with header fields has always been a challenge, but this was much more bizarre than usual. I had tried what Utah suggested, putting the code that sets the header fields in multiple locations, but that didn’t help. I was so far in to the custom version that I couldn’t really walk back my changes to see what broke it.
In the end I was able to sort of sweep the problem under the rug because when I set up an Advanced Print Routing workflow to email/print batches, the header issues went away. I concluded it was because the routing workflows have a “break” widget in them that makes it behave more like printing one invoice after another than behave like printing a batch.
I would love to know what the root cause is, I never found one.
2 Likes
That’s crazy Tom, I feel like I had this issue at some point too.
“Sorry for the wait. It does not return anything, no.”
That is why the PO number is wrong on the second page. What you may try is to make “Keep Together” on the PONum group = false. This will make it so that the group can go onto the next page from what I can tell. Maybe then the PO num will return something?
In any case, I am just trying to come up with anything. The fact that base works is telling and if you can it may be worth adapting that one again.
KeepTogether is already set to false for Group1.
While I was checking that, in Group 1’s Properties, I found this:
Is that the right variable? I’ve never used the Document Map feature, and I don’t know what it’s doing, but wasn’t it the PONum.Value that doesn’t return anything? I may be way off, but I thought I’d ask.
I’ll probably recreate the custom form since I haven’t been able to fix this one.
Hi Tom,
Frustrating, isn’t it? I think I’m in the same boat as you are now - too many changes to walk back. I’ll probably recreate it, but I wish I could find the issue. Thanks for letting me know I wasn’t the only person this has happened to. 
Yes! Absolutely maddening! I feel like there is a bug somewhere, but good luck going to Support with a “bug” on your custom report that doesn’t exist on the base version… 
1 Like
Never used a document map on an SSRS report… at least not knowingly.