Dynamics Business Central / NAV Developer Digest - Vol. 448
ArcherPoint’s Developer Digest focuses on Microsoft Dynamics 365 Business Central and Dynamics NAV development. This week’s volume includes discussions of issues with report data, Visual Studio Emulator for Android, large datasets, and more.
The Dynamics 365 Business Central community comprises professionals devoted to advancing the success of their customers. Developers, project managers, and consultants collaborate to share helpful information across blogs, forums, and social media sites. From discovering new solutions to finding answers to complex issues, these dedicated individuals are constantly sharing their knowledge with others. At ArcherPoint, we recognize and appreciate this highly engaged community’s creativity, hard work, and collective intelligence. To ensure all users can benefit from their expertise, we want to share their wealth of information with everyone.
Developer Tip of the Day: Report Data
Kyle Hardin shares the latest: “You can get BC to export a report dataset without formatting in case you need to verify that the data is correct. Run the report, then do Send To and choose Microsoft Excel Document (data only).”
Issues with Visual Studio Emulator for Android
Anton Modaresi asks: “I’m trying to get the Visual Studio Emulator for Android going, but it gets stuck saying OS is starting and eventually fails with an error message. I haven’t been able to find a solution. Before I abandon the project and try a different emulator, has anyone else tried it? The error I’m receiving is as follows:
[Window Title]
Visual Studio Emulator for Android
[Content]
The emulator is unable to connect to the device operating system:
Couldn’t auto-detect the guest system IP address.
Some functionality might be disabled.
[Close]
Things I’ve tried after googling about it:
• Re-install everything
• Disable wifi adapter
• Let through the traffic in windows defender firewall
• Turn off the firewall
The log at C:\Users\amodaresi\AppData\Local\Temp\emulatormgr.android.log only says:
3> 7/19/2023 1:01:22 PM : [Informational] Waiting to launch device…
3> 7/19/2023 1:01:22 PM : [Informational] Launching Device: 4.7″ JellyBean (4.2) XHDPI Phone
3> 7/19/2023 1:01:22 PM : [Informational] Validating emulator arguments…
3> 7/19/2023 1:01:22 PM : [Informational] Determining if emulator is already running…
3> 7/19/2023 1:01:22 PM : [Informational] Preparing virtual machine…
3> 7/19/2023 1:01:26 PM : [Informational] Launching emulator…
I can’t find the log of the device itself. The adb command line tool that is used for that – C:\Program Files (x86)\Android\android-sdk\platform-tools>adb devices – returns an empty list of devices. So, I used BlueStacks for the LS Retail app I was trying to run, and that worked fine.
Then a Microsoft tutorial got me back into this: From Visual Studio itself, you can open the Android device manager from the toolbar from a MAUI (multi-platform app user interface) project. It let me download a default Android image for Pixel 5 – API 33, and it works; I can run the thing from visual studio. Hello, world…MAUI!!!”
Updating a large number of records in a dataset
Yann Saint-Laurent queries: “I have a question regarding updating a large number of records in a large dataset. I wrote a piece of code I thought was good and ran properly on our customer’s test environment until we imported all their customer records, around 500,000 of them. Originally, I was working with ~30,000 records.
The tool I built allows the synchronization of Parent to Child customer fields. I created a table that stores all the fields from the customer table; you can go to the list page and select which fields you’d like to sync between the records.
Now, on the customer list, I am asking a Parent customer to push its fields to all the Child customers, but in the original dataset, even updating 3,000 records was pretty fast, but now it has come to a crawl—5-10 seconds per customer.
I tried all sorts of ideas to optimize it, but it is still not fast enough. I’m using RecordRef and FieldRef to dynamically update the data in the table, and I’ve tried to push the update to the Scheduled Task, but it also creates table locks while it is running for long periods.
Any suggestions would be appreciated.”
Kyle Hardin asks: “How often do they update customers?”
Yann replies: “Not frequently. It’s more of a maintenance tool.”
Kyle continues: “As long as the customer updates aren’t too frequent, what they are asking you to do and the fact that it takes 10 seconds…that sounds reasonable to me. The only other alternative I can think of would be to job queue the child table updates.”
Tom Hunt joins the conversation: “Have you considered adding explicit COMMITs every so often? Maybe every 500 records or so? It’s possible that there’s an overwhelmed cache somewhere that needs to be dumped via explicit COMMIT.”
Yann responds: “Matt T. suggested the same thing, but I ran the Import Export Power Tool from Insight Works yesterday, and it was able to update 400,000 customer records in the same environment in under 34 minutes. It errored out a few times, and everything was rolled back very quickly when it errored, so this would mean they are not using COMMITs.”
Elyes Ferchichi makes a suggestion: “You can consider Queries for the table you created to store all the customer fields with the property DataAccessIntent = ReadOnly. Combined with filters on the Query columns, it could improve data access performance. Also, maybe run through this not-to-do list and double-check if anything from Microsoft’s Efficient Data Access article it is in your code/logic.”
Kyle continues the conversation, asking: “Does DataAccessIntent = ReadOnly do anything in SaaS?”
To which Andy Alldredge responds: “Yes, it allows for this: Using Read Scale-Out for Better Performance – Business Central | Microsoft Learn – in that article can see the link back to DataAccessIntent Property – Business Central | Microsoft Learn.”
Funny of the week
Kyle Hardin shared this one, which we can all relate to:
Interested in Dynamics NAV and Business Central development? Be sure to see our collection of NAV/BC Development Blogs.
Read “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.