Dynamics Business Central / NAV Developer Digest - vol. 293

Dynamics Business Central / NAV Developer Digest - vol. 293

The Dynamics NAV and Business Central 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/BC experts and devotees around the world. We hope these insights will benefit you, too.

Business Central 16 Printing

Kyle announces: “BC16, awesome. I am now doing code experiments to see if I can directly print from code to a printer without any user intervention. Will report back shortly.”

Jon quips: “I heard it prints money.”

Debbie joins in on the fun: “Or does it print toilet paper?”

Kyle reports: “I cannot make direct network printing work. They added the ability to intercept the PDF file in transit, which is a good thing, so it is easy to attach it to an email (or email it to a cloud-ready printer with an assigned email address), but there still is no mechanism for cramming the report output directly into a print queue. So, I will keep having to use a PDF rendering engine to do the printing in an external process, which is yucky and error prone.”

David is disappointed: “That’s a shame; one of the biggest limitations with BC is printing, and I was hoping that BC16 would get around this.”

Kyle adds: “I should clarify. Direct printing will work without user intervention as long as the printer is cloud-capable. The printer would have to be able to receive an emailed print job. This is true whether working with BC SaaS or on-premises. My particular situation is on-premises, and the printers are older, network, multi-function copier machines. There won’t be any cloud anything out of those without replacing them. But they did not add a mechanism to actually print and use the Windows server print engine. This last part wouldn’t work in SaaS at all, but I was hoping they did something for us lowly, on-prem people. I might see if there is something I can do with dotnet, but my problem still remains that I have no method of taking a PDF and turning it into a print job without a PDF rendering engine.”

David asks: “So if I am running BC16 on-prem, and I have an external device (handheld reader for example) and I want to automatically print out some product labels upon receiving, is this now possible in BC16?”

Kyle replies: “Out of the box, not that I can see. I’ve taken apart codeunit 44 Report Management and the new Printer Management tables and codeunits in the System Application, and I do not see a way to do it. But I’ve only been experimenting for a short time.” 

Business Central 16 Enums

Kyle apprises: “Many old option fields were changed to Enums in BC16. T38.Status and T39.Type are examples.” 

Matt T reacts: “That means you can have custom statuses, document types, and line types without modifying base. :)”

Kyle expands: “It has resulted in a million a six compiler warnings. And I’m not sure why, because those show up even for the base application. And even more confusing: I do not know how to fix it—even if I re-write my code, the syntax for getting at a specific Enum value is exactly the same as getting at a specific option value: field::enumvalue 
if (Type >= Type::”G/L Account”)… 
  
An implicit conversion is being performed from a value of type ‘Enum “Sales Line Type”‘ to a value of type ‘Integer’. This conversion can lead to unexpected runtime issues. This warning will become an error in a future release.”

Bill W shares this GitHub article regarding TestField does not support Enums, adding, “I can help with the ruleset to ignore it.”

Is There a SQL Table Where AL Objects and Properties Are Stored?

Kyle asks: “Is there a SQL table where AL objects are stored with some of their properties? Or is the AllObj special table generated some other way? I see the table Objects, but that is a hold-over from C/AL that hasn’t been retired yet. In BC15 and BC16, that table is empty.” 

Syed responds: “There is a table called NAV App Object Metadata, which stores some info related to the Tables in the Extensions.”

Kyle continues: “And Microsoft stopped using it in BC16. I was attempting to do some SQL query magic to get a list of retired and added objects, but I need the BC16 list to do that.”

Syed adds: “Until BC15, we have used this table. BC16 we need to check.” 

Matt T queries: “Just curious, what do you need it for?” 

Kyle responds: “A client has the most detailed security setup I’ve ever seen. They have hundreds of permission sets defined, and every page, table, and report is specified. The default is no access, unless specific access is granted to an object. I’m about to put a BC16 update database in front of them for testing, but we have to update (add new, remove obsolete) object permissions. This was not easy:

  • I pulled up All Objects in BC16 and saved as Excel.
  • Converted to CSV on the type, ID, and name. 
  • Did a search/replace the various object types on their integer replacements. 
  • Removed redundancies like Table/TableData and all of the Page and Table extensions.
  • Did a bulk import into SQL into a new table I created. 
  • Then I was able to do some SQL voodoo to get my exception list: 

  
select a.[Object Type], a.[Object ID], a.[Object Name] 
from [15].[dbo].[NAV App Object Metadata] a 
where not exists ( 
select b.[Object Type], b.[Object ID], b.[Object Name] 
from [15].[dbo].[Kyle Object] b 
where b.[Object Type] = a.[Object Type] 
and b.[Object ID] = a.[Object ID]) 
order by a.[Object Type], a.[Object ID] 
  
Then reverse the direction of the query to get your list of objects in BC16 and not in BC15.” 

If you are interested in Dynamics NAV and Business Central development, be sure to see our collection of NAV/BC Development Blogs.

Read the “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.

Trending Posts

Stay Informed

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