We old dogs really have to learn new tricks with RTC (RoleTailored Client), as I found out couple of days ago. A customer of mine asked me for a quick report. I don’t typically do reports, but I thought—“not a big deal, it’s just a report”—so I fixed it, tested it, made sure it worked, then deployed it to production.
And then I found out it was not just a report.
It just didn’t want to execute in production. Whatever I did I just got a strange error message, something I never saw before. Ever.
Anyway, it went like this. I created the report and tested it in development environment, when I made sure it did what it was supposed to do, I exported the FOB, imported it into production environment, and went to the see the user to confirm that it shows correct figures from production.
Instead of him seeing figures, I saw a different figure: go figure what’s going on.
I exhausted my knowledge of Norwegian language right after the first word, but I had to give it a try. I opened the Classic client on user’s machine using my credentials, and kompileringened the report. It worked.
The user was happy, kind of, and has given me a couple of nice-to-haves, while I was wondering how come I didn’t kompileringen the report before deploying. I was sure it was compiled.
When I came to my desk, I completed the wish list, then deployed the report again.
And then I got an e-mail from the same user, again with the screenshot above.
Now this is strange.
I started the RTC, connected it to production, started the report, and here it goes, the same error for me, as well. But I know the drill, right? So I open the Classic client, compile the report, and check.
But now it fails!
It was a wild goose chase for a while, and I couldn’t really figure it out. The same report works in development, but in production it fails. From the same machine, from the same instance of RTC, for development it works like a charm (except it looks ugly as any default non-polished RDLC report), but in production it crashes yelling at me half in Norwegian, half in English, and complaining about some DLLs I really can do nothing about.
It was funny, at about the same time, Mark was writing about similar issues with RDLC reports. But none of the steps Mark (or his commenters) suggested actually worked.
Then I checked the version. I knew that both development and production are on NAV 2009 SP1, but still.
And there it was, hidden in the build number. “Normal” NAV 2009 SP1 had version number 6.00.29626. The development environment, though, had a different one: 6.00.31085. Ok, there we go.
I connected to the production remote desktop, opened the Classic client, merely compiled the report, and guess what—it worked. And of course, there was a hotfix deployed in development environment because of an error with Web services, and it seems that it (hot)fixed more than just that. For some reason, it prevented execution of a report.
So, here comes a new trick for me, the old dog: always make sure that the object is compiled and used under exactly the same build number. This didn’t cause any issues in previous versions of NAV, especially not within the same product version, however in NAV 2009 it is obviously not the case anymore.
This Post Has 3 Comments
Pingback: Strange errors in RoleTailored Client RDLC reports - Navigate Into Success
I had kind of the same wonders of NAV nature. Our client had all coponents hotfixed (rtc, service tier) but not the classic client.
The role center started to fall apart when he change some pages.
So indeed, your conclusion is correct to do this for ALL objects, not just reports.
@Marcel: yes, it seems to be the case with pages as well, so it’s nice to know that now we need to live with this issue in NAV. Thanks!