ArcherPoint Microsoft Dynamics NAV Developer Digest - vol 14
The ArcherPoint technical staff—made up of developers, project managers, and consultants – is constantly communicating internally, with the goal of sharing helpful information with one another.
As they run into issues and questions, find the answers, and make new discoveries, they post them companywide on Yammer for everyone’s 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 group—so we thought, wouldn’t it be great to share them with the rest of the Microsoft Dynamics NAV Community? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from the ArcherPoint staff. We hope these insights will benefit you, too.
Michael Heydasch on anomalies with the Job Queue and NAS in NAV 2013:
I’ve experienced many anomalies w/the Job Queue and the NASes on NAV version 2013, leading me to believe the NASes are not as stable on the 64-bit service tier as the older NASes. Microsoft has been involved almost from the get-go. We’ve separated the NASes into dedicated service tier instances, created one instance for each job, etc. For months I was restarting the NASes overnight…turns out MS has acknowledged the NET STOP and NET START via the AT scheduler is not ideal for restarting the NASes. They provided a PowerShell script.
NOTE: The Restart-Service line had to be revised to:
Restart-Service $ServiceName.Name
Param(
[string]$NAVServerName
)
function StartService([System.ServiceProcess.ServiceController]$ServiceName)
{
Restart-Service $ServiceName
While ($ServiceName.Status -ne "Running")
{
Start-Sleep -Seconds 1
}
Write-Host $ServiceName.Name "has started." -ForegroundColor DarkCyan
}
if ($NAVServerName -ne '')
{
$NAVServerName = "MicrosoftDynamicsNavServer$" + $NAVServerName
}
ELSE
{
$NAVServerName = "MicrosoftDynamicsNavServer"
}
$DynamicsServer = Get-Service -Name $NAVServerName
clear
Write-Host "Starting:" $NAVServerName -ForegroundColor DarkCyan
StartService($DynamicsServer)
Write-Host
Write-Host "Done" -ForegroundColor DarkGreenAlan Campbell on Agile Design vs. Waterfall Design
BDUF stands for Big Design Up Front. It is what’s known in the waterfall world as the “Design Phase” – a period of time that can last anywhere from a couple of weeks to a couple of months where designers can take the project’s requirements and ideate, at length, over how the solution will manifest in interactions and aesthetics. Designers will typically explore various workflow options, data collection tactics alongside aesthetic, layout, and typographical treatments. Even with the addition of a Sprint 0, which allows designers one sprint to get “ahead” of the development team, BDUF vanishes. Designers new to Agile will protest that they are not given enough time to think about the solution and that in no way can they turn around a design in the given timeframe. This resistance alone can quickly kill the momentum of an Agile team.
To understand how to resolve this issue, we need to examine its root causes first. BDUF allows designers time to think about the entire experience the team is building. The expectation is that at the end of the design phase, the entire product is designed and spec’ed out. In addition, this is typically the first and last time the designer will get to spend a significant amount of time on the project so everything must also be right as there’s no (significant) going back.
When introducing Agile to designers, it is imperative to stress that they focus on only a sprint’s worth of design work. In fact, they should hesitate to design too far “ahead” of the development team as priorities may shift after each incremental release and that additional work may go unused. Focusing on a sprint’s worth of work dramatically reduces the workload for the designer. All of a sudden, turning around a much smaller amount of design work becomes much more realistic in the given timeframe.
Second, Agile is iterative. There will be another sprint and it will provide another opportunity to refine and build on the work currently being implemented. The waterfall designer’s mindset doesn’t expect that. The expectation is that the work will be launched never to be touched again. By convincing your designer that this is the first iteration of the implementation, that learnings will be collected and that subsequent iterations will give her opportunities to update, improve and resolve the UX you begin to alleviate the concern that a less-than-finished piece of design is released to customers.
Read more: Top 3 Reasons Designers Object to Agile and How to Overcome Them
Dan Sass posted a link on using the NAV 2013 R2 Bulk Insert when in debug mode:
“…when you enable debugging in a scenario that falls into a violation of a Primary Key in SQL Server due to several concurrent INSERT calls, you might find that the Microsoft Dynamics NAV Debugger will not stop in the exact INSERT statement but, due to delayed Bulk Insert, in a position right after the INSERT AL Statement sequence.”
Read the entire post on the Microsoft Dynamics NAV Team Blog, Debug and Bulk Insert in Microsoft Dynamics NAV 2013 R2.