The NAV community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of sharing helpful information with one another to help customers be more successful.
As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media...so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV experts and devotees around the world. We hope these insights will benefit you, too.
Kyle shares an important safety tip: “If you are running in NAS and using .NET variables, make sure that the property RunOnClient is No.
There is no client in a NAS, only on the service tier side. And the error message that you get when the NAS entry fails isn't very helpful. What the heck is a client callback?”
The error reads:
Microsoft Dynamics NAV Server attempted to issue a client callback to create a DotNet object: System.IO.File (CodeUnit 50000 HLS Functions). Client callbacks are not supported on Microsoft Dynamics NAV Server.
Brian asks, “Isn’t the client callback when a user interaction box is instantiated?”
Kyle responds, “My code didn't generate any user interaction. It was a simple file open, process, close algorithm. And as soon as I changed the .NET variables to RUNONCLIENT=NO, it started working fine. That was the only change I had to make.
Brian then asks, “What if it was a .NET or OS dialog box, like an OK for replacing an existing file? IDK, just guessing.”
Suresh chimes in, “You get client back error whenever a window is opened, it could be an error message box, confirmation box or window to choose the file path.
By default RunOnClient is No for .NET variables unless you want to run the component on the windows client.”
Kyle replies, “I still say if it were something user interface, it would have died running in a NAS even with runonclient=no.”
Suresh agrees, “True, whether the runonclient is yes or no if there is any window open the process will fail, but when you set RunOnClient property to yes I know there will be a dialog box which will open to get the permission, whether to run the component or not. I am thinking that might be the issue in your case.
I may be wrong this could be the cause. See Kauffman’s post, NAV Client Needs Permission to Run External Component.”
In this post by Microsoft, they share the latest updates to the NAV development tools including reordering columns with drag and drop functionality and report application objects now supported using new syntax to allow for inclusion in your extensions.
Here are this week’s articles we hope will inspire you:
Don’t Sell a Product, Sell a Whole New Way of Thinking
How to Accelerate Learning on Your Team
Enjoy and we’ll see you again here next week!
Stay abreast of what is new in the Microsoft Dynamics NAV community and at ArcherPoint by subscribing to our monthly newsletter, Better Business, by completing the form in our Resource Center.
And, if you are interested in NAV development, be sure to see our collection of NAV Development Blogs.