Blogging about your own mistakes is always easiest. Reasoning is simple; if I make the mistake, chance is someone else makes it too.
Yesterday we had quite some panic at one of my large customers. After importing a fob file with some (small) changes some reports started to break that were not changed by the release.
Not all the users were suffering from this, only few, and after restarting the client, at first, the issue seems to be resolved.
However after a few hours we had the issue returning at users who had already restarted so we had some panic since it kind of goes against one of NAVs strong principles. Consistency. IF you have issues with NAV it is always relatively easy to reproduce.
Fortunately this was the case after some testing but debugging and restarting the client did not change the issue. It persisted.
What do you do in cases like this? Scream loud and wave your arms? No. Stay calm and look for differences. ;-).
After some thinking I realised that I had not restarted the service tier after importing the FOB. This “should not” be required since the new metadata is picked up automagically. However after restarting the service tier the issue was solved.
Since the issue was with a report, I emailed back and forth with Michael Nielsen who does first line support of the reporting tool we use, ForNAV. He confirmed quickly that importing a fob MAY cause inconsistency in your metadata and it is an issue that is very hard to troubleshoot or even reproduce with NAV.
So I’ve learned my lesson and will from now on always restart the service tier after importing fob files.
would compile the objects do not even work?
In my experience it’s usually not a problem with a single server/NST for small fobs. Specially when multiple NSTs are involved, they sometimes get out of sync and sh*t starts happening.
I encountered the same problem a few times, but a recompile of the imported objects usually fixes the issue without the need to restart the ST, I therefore though myself to always recompile newly imported objects and test that everything works afterwards. I only restart as a last resort to prevent the warm-up period for the ST.
Thank you. Nice to see my caution has been justified! Have always recommended this, though recommendation not always followed. Now I have a real life case to back it up.
Same here… onafterinsert event trigger was no longer executed on a second tier (with compiled objects). Restarting the tier fixed the problem… very dangerous, so: ALWAYS! …. etc.
LikeLiked by 1 person