ArcherPoint Dynamics NAV Developer Digest - vol 56
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.
Faithie Robertson on upgrading tables in NAV:
The Upgrade team has been working with a lot of reports lately that are parts of business contracts. These reports are heavy on text strings and special formatting. There are requirements for spacing, line placements, etc… that have made them tedious and even painful to maintain. We’ve found the best way to handle these is with a tablix made of a very small grid of rows and columns (0.5cm x 0.5cm). This allows for cell merging without having to add new columns, and padding can be used to move text that “smidgen” to the right when needed. The rows are all part of a single dataset group, and can be made visible by a variable from the dataset to appear only when needed.
Jon Long on making a database read only:
Ever need to make a database read only? The context is that the client wants to retain access for all users to an old db, but they don’t want anyone to edit anything. SQL has a way to make a db read only, however this causes errors when NAV tries to modify personalization tables on login.
It turns out that SQL Server Manager allows you to add a ReadOnly property on a db:
Options > State > Database Read-Only
Alan Campbell shared an article on Agile project management:
This is an interesting article that says that an organization shifting to Agile from Waterfall is not simply a directive from upper management, it is a totally different way of looking at development projects. Although the results are worth the pain, management cannot expect everything to change overnight – there is a learning curve and a cultural shift within the development, project management, testing, and analyst staff to make the transition.
Read the article: Agile is a Cultural Revolution
Quote from the article:
To me two things are key culturally – accountability and ownership. It is scary for team members to be held continuously accountable. Simple fact of the matter is that Agile is demanding. Very demanding. Mistakes are exposed immediately. Lack of progress cannot be buried in vague project reports. The project burndown tells the tale every day no matter how we choose to spin reality. The team is collectively exposed and held accountable in a manner they have likely never before experienced in their professional careers. Pathologically, it is not uncommon for Agile teams to look really disorganized and chaotic compared to their Waterfall counterparts in the same organization. The reason is not that they are inherently stupid or became incompetent once they switched methodologies. The fact is that the methodology is forcing issues to light to be fixed right away that are hidden in Waterfall until it is too late to do anything about it.