ArcherPoint Dynamics Developer Digest - vol 145

ArcherPoint Dynamics Developer Digest - vol 145

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.

Running Dynamics NAV 2013 Application on a NAV 2017 Platform

Don’t do this. Sure, it is supported by Microsoft. Your partner may have even suggested that you do it. But, why on earth would you? Jon Long shares with us, it is possible to run a 2013 DB NAV Application version 2013 on a 2017 Platform. Microsoft even has instructions here: https://msdn.microsoft.com/en-us/dynamics-nav/converting-a-database. He was curious, so he submitted a support ticket with Microsoft about running a 2013 DB NAV Application version 2013 on a NAV 2017 Platform.The Microsoft representative stated, “We would do our best [to support it] for now as documentation states it’s ok. I can say from personal experience with 1000s of support cases, it’s not a good idea. I can see so many issues that would take so long to resolve, test, so many new bugs and scenarios that development hasn’t accounted for that it’s not worth it.”

Kyle notes, “I would never tell a customer this option is available. It seems as if in NAV 2013 there is a very close link between the objects and the platform that mismatches, creating a ton of problems. Problems that would take far less time to solve by simply applying the object upgrade to make objects match the platform build.

Why would a customer want to do this?

And why would any partner recommend something that could have such a negative impact on an upgrade?”

Is the Debugger Function in C/AL Bug Ridden?

Kyle asks, “Have any of you messed with the DEBUGGER.BREAK function in C/AL? It would be cool to be able to do this:

IF OrderNo = ‘156’ THEN
DEBUGGER.BREAK;

Matt says, “You can set conditional breakpoints, although I’ve never had much luck with them. https://msdn.microsoft.com/en-us/library/hh168561(v=nav.90).aspx”

Bill replies, “Does that mean you’ve never had them work or they sometimes work? I don’t think I’ve ever had one actually break.”

Jon chimes in, “Visual Studio has had conditional breaking since 2002. I think we’ll get it in 2018.”

Matt replies, “It means I spent all of 5 minutes trying to get it to work and was unable. I was in a hurry so I did a debug hack instead. Put in a conditional of “IF whatever THEN” and a meaningless line underneath it with a breakpoint so it would only break on my “whatever” condition.”

Bill responds, “I swear this has never worked in “the field.” I just tested with a conditional set for i = 39 and it worked. So many hours wasted hitting F5…”

Debugger break just throws an error and stops debugging, so you wouldn’t be able to continue on after you hit your target value. 

WHILE i <= 50 DO BEGIN IF i = 40 THEN DEBUGGER.BREAK; i += 1; END; Kyle, “I couldn't get it to work either. I was trying it in 2015, which might be part of my problem, but it would either hang, complain that I wasn't debugging yet, or complain that it was already debugging and couldn't break. Don't give me functions that compile in C/AL and then don't work. It gives me confidence problems.” Bill notes, “I think that's the intended function of DEBUGGER.BREAK, it ends the debugging session. That's what I would get too, 'session not debugging' or similar, which is true, I'm no longer debugging that session. If I set my conditional at i = 39 on the WHILE loop it would stop. If I continue and hit the BREAK my debugging session stops.”

Leadership Lines

I really like this article that explores the possibilities that not only what we eat and how much we exercise, but also our thoughts, have an impact on how quickly we age.

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.

Trending Posts

Stay Informed

Choose Your Preferences
First Name
*required
Last Name
*required
Email
*required
Subscription Options
Your Privacy is Guaranteed