This blog is as much as informative and subject to change/discussion.
At one of my Dutch customers we are implementing two subsidiaries in Lithuania. These are simple offices that do accounting, sales and purchases with pretty much standard NAV which also the HQ does.
Since the LT localisation is not very exiting we decided to have them all in one database. I know this is not officially best practice from a technical and upgrade point of view, but as most of you know the advantages of having it in one system weigh more than the disadvantages.
The implementation goes very well as for training, setup etc. But today we ran into an unexpected issue. I think...
I already realised that we would run into the codepage issue as described in my blog.
I took this as a fact and disabled the flag, told the management and users what to expect. Everyone happy.
Until we went into the Terminal Server. We are running Terminal Server 2008 and for what we have found out (and I am not expert) we can only run TS in one codepage that is determined at startup. So we figured, what if we use the LT codepage? Would that effect Dutch users. Testing proved (we tought) that this would work as we don't have strange characters in NL and the LT ansi codepage has all dutch characters.
But then we got a call from order entry that tbe barcodes where not printing anymore. Investigation proved that the barcode font is also ANSI based and did not work on LT codepage.
Al and al I did not have a very good feeling about running NL on a LT codepage and we decided to create a new terminal server for the LT users since we have VMWare and a TS license is not that expensive.
Any feedback? Has anyone managed to setup TS with multiple codepages for different users?
This week I got an email from Thijs den Hartog that he was experiencing weird behaviouor of classic reports after doing dome updates of the binaries of Dynamics NAV.
Also this week I read an announcement on the NAV Teamblog that they introduced a new feature called Metadata versions since updating the binaries require a recompile of all objects.
Dit you think I was smart enough to link these two?
But after another email from Jorrit Mertens that they found out that their solution was a recompile I did.
So this seems to me an important update for all RTC users.
Just a sidestep: At my RTC implementations I do not use classic reports anymore and since Microsoft reccomends not implementing hotfixes unless you explicitly eperience the problem that the hotfix describes I recommend both.
Thanks Jorrit and Thijs for allowing me to share this valuable information.
Enjoy your sundays.
With my previous post I unintentionally caused quite a stir between the partners who develop tools that allow us to manage our development, not just because my big mistake in thinking Mergetool was not yet updated to pages, which it was, but also in my firm opinion that metadata and tools should not be in a customer or development database.
So I believe that this deserves more attention, explanation and clarification.
This post is solely my option on this subject. I have been involved in Dynamics NAV development since 1999 and been busy with managing this ever since. I’ve tried many ways and my current opinion is based on this experience.
As for the iFacto ReVision tool, you should know that Eric Wauters (Waldo) used me as a sounding board for their ideas, so it is not a surprise that this tool is based on my current opinion of how object management should be done. However I do not own any shares in this tool or the company, and I am not using the tool in my own projects.
Both at Directions USA 2010 and NavTechDays 2011 I presented a session called “Tools and Tricks that make development easier and more organized”. In this session I spent a lot of time on how to manage objects. Reasons for this are both that many partners are struggling with this and doing it the wrong way. But when it comes to managing development there is much more than managing objects. Methodology and standards are a big part of this. No matter how good your objects are managed your development will be a mess if all your developers use their own standards.
This first post will be about managing your objects and is hopefully the start of a series, depending of the comments and reactions.
Other parts may be about methodologies like Waterfall & Scrum, Architecture, Standards and maybe even the CfMD label in this context. I would also like to write about how the object designer can be changed to accommodate our needs.
Whenever you change an object in Microsoft Dynamics NAV it’s nice to document why you have made that change and if you develop a feature that requires you to change more than one object you want to know which objects are changed when you move this feature into another database. That is what Object Management means in a nutshell.
The object designer does not allow you to do much with this information. There are four features you can use.
Whenever you change or create an object in the Object Designer the modified field is set to Yes. It is considered best practice to disable this flag whenever you move objects out of the database into another system. Doing this the modified flag allows you to manage all changes.
Mike does development for a company called Contoso. The database does not contain any unreleased changes so none of the objects have the modified flag set to “Yes” and there are no other developers in the database. Mike changes three objects for his development project. By filtering on the Modified flag he can easily see what he has done and which objects to export when he is finished. When Mike is finished he clears the Modified flag to “No”.
As you can read in the example this method have many limitations. It only allows you to work on one issue at a time and requires you to export them before starting on a new change. Other than the export file there is no history of the change that is easy to see for others.
The Object table has a field called Version List. This is a text field that allows you to store 80 characters. The field is used by Microsoft and indicated the last version the object was changed and if it was changes for localization, also with a version number.
If used fully by Microsoft, the field allows us to add maybe 60 characters.
John has also been asked to make a change in the Contoso system. He works on the same database as Mike. This means they cannot use the Modified flag anymore. They agree to update the version list field with their initials so they can see who has modified which object. When they export the objects they remove their initials so the version list is clean.
Mike wants to keep track of changed objects per change request. He decides to assign numbers to each request and add this number to the version list.
The first example requires both developers to manually populate the version list field. The second example will run into issues when the limit of 80 characters is reached.
Each object in Microsoft Dynamics NAV allows you to write a book in the Documentation Trigger. This trigger is not used by Microsoft and ships blank with the product.
Each field in the Tables also has a Documentation property.
John needs to fix an issue in one of the changes that Mike has done in the Contoso system. Because Mike always explains his change in the documentation trigger making it easier for John to find the place that Mike has modified.
As with the Version List, using the Documentation trigger is not mandatory for developers making it easy to forget. Also finding a balance in the details of the change can make it difficult to read them. Solutions with a long history might have so much documentation that it’s no longer easy to find the information required.
Version 2009 R2 of Microsoft Dynamics NAV got shipped with a new feature Object Locking. This process can be done both manually and automatically and will update the Locked and Locked By field in the Object List.
Object Locking is mainly intended to prevent developers from working on the same objects and not to implement versioning. In fact, when used automatically the locked flag is already activated by opening the object and left that way even if the object is not changed and only looked at. This makes it difficult to use.
The Locked and Locked By fields are NOT exported when the object is moved to another database.
Before we can proceed to solutions to more advanced Object Management it is important to talk about the difference between an object version and releasing objects.
Each time something changes to an object, it is a new version of the object that can be compared to the previous version, but from a change request perspective a specific version of an object is not interesting. A change request is a group of objects. This group will move from one database to another.
When we release in Microsoft Dynamics NAV we don’t release objects, we release a feature or a couple of features. This release only makes sense if all objects in the release work correctly with each other and the new feature works.
From a business perspective it is more interesting to version these features as packages than versioning the individual objects.
Basically this means we are versioning to entities. We’ll have different versions of an object and when a change request ships as a package this will have a version to.
If we put this theory in a schema the change request is the central object. The Change Request leads us to change one or more objects. When finished, one or more change requests will be released as a package, being a combination of changed objects allowing you to use the new feature in another system.
When two or more change requests require a modification in the same object we cannot release them separately unless we develop them one-by-one. Therefore a release can and sometimes should contain multiple change requests that are dependent of each other.
Even if you can do everything in Microsoft Dynamics NAV, does not mean you should do everything in it. Why is that, you might ask. Isn’t the development database the most ideal place? The answer is “No” and I’ll explain why.
The Microsoft Dynamics NAV database contains a minimum amount of metadata. Each object has only one version and does not know about its past. Reason for this is simplicity which is a very important feature of the product.
In software development it is also best practice to remove additional metadata and go into production with a clean system. Microsoft Excel 2010 does not contain information to be compiled to go back to Excel 2000 or any version in between.
Development databases need to be refreshed from time to time. The data gets old, or even corrupt. If your metadata would be in the Development database and not in the Production database it becomes increasingly difficult to easily replace Development with a fresh copy of Production.
Also from time to time you’d want to develop in another database than your development database, for example making a quick page or report change in a production system. In a test system, after running conversions, you might want to make some minor changes without going back to development and release back to test. And large organizations may have multiple teams working on different parts in their own separate development databases.
Al these scenarios are not supported if your Database Management tool is bound to one database.
If your Database Management Tool is inside your Development databases you’ll create a new task of managing the tool. When you start a new project you’ll start with the last version of the DevTool. But an older project might run an older copy of your tool.
A solution to this might be to manage your development with a tool that resides outside of Microsoft Dynamics NAV and has only one copy. This way, you won’t have to import management objects into each database, you won’t have to move metadata from one database to another and have one running version of the tool.
Does this mean the tool cannot be developed in Microsoft Dynamics NAV? Well unfortunately yes, since it requires a different kind of application that is able to reside inside your windows environment and “spy” for changes that happen in these systems.
Really? Isn’t there any other way? No, not unless Microsoft offers another way of managing objects.
There can be several places to store your changes. It can be one of the well-known repository systems like Team Foundation Server, Visual SourceSafe or SubVersion. Problem with these repositories is that they don’t know Microsoft Dynamics NAV syntax.
My wet dream is a combination of having an external tool that catches changes, saves the data in a repository, but the repository can also be a Microsoft Dynamics NAV database, as long as it is a database that stands alone from the project databases such as production, development etc.
This way you keep your Microsoft Dynamics NAV database nice and clean from external tools and take advantage of the possibilities of all the tools that are out these.
Currently there are three big vendors on the market that deliver Development Tools for Microsoft Dynamics NAV.
Object Manager (Advanced)
ReVision Source Control
Currently Idyn is by far market leader with their product, and it’s a great product that goes way beyond Object Management as described. It is completely developed inside Microsoft Dynamics NAV, stores data in the Development and Production database and last but not least, the code is scrabbled. Object Manager has a free version but the cool stuff is in the paid version.
ReVision is a tool that resides outside Microsoft Dynamics NAV and just scans changes from any database that is open and connects that to a repository. In my opinion that is exactly how it should be. However, ReVision does not have change request management and/or all the nice extra features that the Object Manager Advanced or MergeTool comes shipped with. And ReVision does not have a free version. However Change Requests are scheduled for the next version as are making releases of objects. Since ReVision is running inside Windows the tool can do other great things such as start the correct Client with a single mouseclick directly in the correct database and it has a great roll-back feature, although the latter is in my opinion always dangerous with Table definition changes.
MergeTool is has a different approach than Object Manager Advanced and ReVision. MergeTool does not “catch” the object changes but requires you to import them via .txt files making it more a repository than a Version Management Tool. Just like Object Manager, MergeTool also has tons of other small tools that make your life easier like a superb internal compare algorithm that can do automatic merges and renumber tools. And best of all, MergeTool is 100% free and OpenSource. Only if you are an end user doing your own development it is a commercial tool.
If there were to be a conclusion it would be that none of the current products match my requirements. But, there is a roadmap to success.
The first solution would be to extend Object Manager Advanced with a tool like ReVision that monitors the system for changes and stores this into the current structure of the application. This would make Object Manager Advanced the repository.
Second solution and maybe more logical from my point of view since they don´t compete is to add the MergeTool as a repository to ReVision. I’m not really sure if that is technically possible since I am not familiar with the requirements that are necessary.
Let’s look at the subject from a different angle. If so many partners have challenges maintaining their solutions, should not Microsoft change something?
As an MVP and as part of the Partner Ready Software team I can tell that this has the attention of Microsoft. Recently the PRS team spent a day on the Microsoft Campus in Vedbæk (MDCC) where we had a chance to present our ideas based on the sessions we had in Antwerp and Orlando. Afterwards we had a discussion with the people who should be able to make decisions and with a guy called Per Rasmussen who is doing a Thesis that touches this subject. This lead to the conclusion and quote: “The core of the matter is exactly the same”.
One of the great things about Dynamics NAV is simplicity. Someone can go into NAV and start changing it if he or she has the proper rights to do so. Whatever Microsoft changes, this should never go away.
Sometimes I hear people talk about layers in objects. Dynamics AX supposed to have something like that where you can stack pieces of functionality on top of each other and therefore it’s a more professional product and supports multi country environments.
Personally I more like the idea of using Namespaces which is something Partner Ready Software came up with.
Namespaces can be pieces of functionality that belong together, like “W1”, “DE” or “NL” but also “ISV1”, ‘ISV2” etc. This would make the versioning list we use today more explicit since we could start doing versioning of Namespaces. It should be as easy to remove a Namespace as it should be to remove one, unless they are dependent of each other. Still I would not like to have more than one version of a Namespace in a database, all the rest should be in the repository.
Namespaces can also remove the need for object & field numbering other than maybe for user rights.
Even though the “backdoor” which is used by ReVision is supported in version “6” & “7” I would like this to be the “official” way of tracking object changes, but as a NAV developer I would like to have the possibility to create a tool like ReVision from within Dynamics NAV. Actually, writing this, my guess is you could if you use DotNet interop.
I would like Microsoft to give us a repository tool that we can build upon ourselves. Making it best practice to separate development metadata from customer databases.
In Microsoft Dynamics NAV we reuse a lot of terminology. Fields like Customer No. and Description are all over the place. Still it’s easy to make a typo and we need to translate the same captions over and over again. This could easily be solved by implementing a Data Dictionary that stores all the most commonly used captions and translations.
I will elaborate more about this and namespaces in the future on the Partner Ready Software wiki pages.
So what about the other tools? This blog post was intended to cover Object Management, my view on the subject and compare this to the current solutions that are available and Microsoft’s responsibility.
If you look at tools like MergeTool and Object Manager Advanced, you’ll see that they are much more than an Object Management tool. In my opinion this should be separated and partly improved by Microsoft.
Let’s make a short list of things that are obviously missing or should be easier in Microsoft Dynamics NAV.
This is probably the single biggest issue that developers run into in their daily job. It has never been in the product although in some versions the menu option existed in the Object Designer even though I cannot remember the exact version.
Fortunately the MergeTool offers this for free, or you can use Notepad if you are familiar with the txt syntax of the object export like I am.
To setup security in Microsoft Dynamics NAV you must totally master all the Design Patterns and even memorize object numbers by heart. When developing a new function, security is part of the process and should be easier to transfer between databases, like is done in Object Manager Advanced.
It should also be possible if a user gets a permission error to have the option “request permission”. This should be as simple as the Notifications in the RTC for a system admin to say “allow” or “deny”.
Generally considered best practice and part of Object Managers deployment is the possibility of export the current status of objects before you import new objects. This should be a simple button on the “import objects” menu.
Client Monitor is a great feature but the output is very hard to analyze. In all my workshops I try to tell people about the Advanced Client Monitor that was available in the Performance Troubleshooting guide for Navision 5.0. This should be part of the standard application rather than the current output.
Object Management is something that can be achieved in many different ways. Everyone should investigate their own strategy and analyze best practices. It also depends if you are Microsoft, and ISV, a VAR or an end user that does in-house development.
Looking at the success of the tool vendors Microsoft is clearly leaving a gap there. The good side of it is that it allows us to make our own choices to store all metadata in the customer database or to use a repository.
From my point of view there is no best-buy on the market today.
So what do I use myself? I have a very small tool I created myself with the help of Jorg Stryk that is in the development database to track changes. I only do this because that is the only thing I can do since I’m not a .Net developer. It has only four tables to store Tasks, Task Objects, Releases and Release Objects.
Everything else I do in the MergeTool which I use as a repository. Thank you Per Mogensen for making this great product.
I hope that one day my dream of a connection between ReVision and MergeTool happens in real life.
Enjoy, and hopefully for nobody any hard feelings…
The information in this post is based on research (yes, this time I did do that).
Nevertheless I might have made mistakes despite of all my efforts. If so, please let me know via the Contact option on this blog and don’t start your own advertisements. It will be moderated.
All the products have videos and most of them I watched. I encourage you to do the same and form your own opinion.
Today, Todd Bergesson of Microsoft confirmed at NAVUG that the classic forms as we have known them since 1995 will be discontinued in NAV "7".
This quote is from MSDynamicsWorld.
The reason for this, Bergeson said, is twofold: First, SQL is the only server option for NAV 7, so when a user is upgrading to 2009, he needs to upgrade to SQL; and second, the Classic Client must be upgraded to the Role Tailored Client using the transformational tool in 2009, because the engine that runs the forms in previous versions will no longer exist.
"So, when you upgrade to 7, and everything's in forms, nothing will run," Bergeson said. "I can guarantee you, the forms aren't going to miraculously change and appear, because that's going to throw the development cycle out by another year. So, that engine is gone. Classic client is gone, so you just need to have that discussion now."
Entire article here
So anyone who wants to use NAV 7, the RTC is the only option. This also means it is mandatory to go through 2009 to upgrade your forms to pages. This has two reasons.
1. The Transformation Tool is not shipped and/or updated for NAV "7"
This means that you would either have to run the old Transformation Tool but against what forms, this brings us to
2. The new funtionality is only in pages
So you cannot merge your forms with "7" forms and go to pages. You MUST merge your old forms with "6" forms, then goto "6" pages and then merge to "7" pages.
This is a mandatory path every upgrade must follow.
And this is old news, but it has never been official until now.
What are the other consequences...
From a development/partner perspective there are massive consequences, namely most partners have built their own development tools within NAV. And they won't work anymore. Let's have a look at the three most popular ones
1. Object Manager by Idyn.
Unless updated to pages this tool will not work anymore, and even then, it will be extremely hard to use since having a page based tool it requires all developers to have an RTC active on their development systeem. Which off course they should already, but still, it is more a hassle
This tool is already updated to pages (thank you Denster, I did not know that), so tool will still work , but the form versions can only be used in old versions.
Here, there are no changes. Clearly this tool has been made with the vision that having a tool that resides within NAV does not have a long term future. ReVision is .Net based and uses an external repository. This tool should be a safe investment.
If you want to test with Microsoft Dynamics NAV 7 you need a x64 machine. Not to run the client, since that is still x86 but to run the service tier and SQL Server.
So when I got invited to Knowledge Transfer 3 as part of the TAP program I needed to make a decision since my system was three years old and back then it was still normal to install x86.
My laptop is only thee years old and was quite good when I bought it, its x64 with enough RAM and a fast CPU but I decided to upgrade the slowest part, the disk and have a Solid State Disk installed and make it dual boot.
I had Windows 7 x64 installed and decided to upgrade to Windows 8 pre beta since I could still boot my old Windows 7 x86. So here are my experiences after a week. Not from Dynamics NAV 7 but from Windows 8.
The system now boots in 4-6 seconds. I love that...
What does it look like
Tiles! That is what windows 8 looks like. Basicaly it is just a big Windows 7 phone. Your desktop is screaming for a touchscreen as soon as you first look at it.
It comes installed with a lot of programs that support the tiles since the UI is different from the older windows versions. All applications use the entire screen and there is no task bar that allows you to switch applications. I also have not found a way to close applications yet. ALT+F4 does not work and there is no [X] in the upper right corner. There is only the task manager that allows you to kill apps.
The tiles are your start menu, the classic start menu that came up from the left bottom corner is dead. When you press start you just get the tiles. Searching for applications is easy, you can just start typing and it will list up.
You can easiliy rearrange the apps by holding them with your mouse to another place. I have not yet found a way to change the icons. I guess all applications must be updated to have the large icons.
As soon as you start a program that is not "Windows 8" ready you get redirected to a sort of second hand desktop that looks like the Windows 7 desktop but without some options. For example, here you also have no start menu. You do have a taskbar, which I still find handy.
What does work
Actually it is quite amazing, I have worked with it for a week at customers, Microsoft etc. You can register in a domain, all network options work so you can basically just do your thing. Or at least, I can.
What does not work
I tried using the RDP "tile" but that seems very bugy. I spend a lot of time on remote desktops and this one just kicks you off every not and then. Fortunately the old "mstsc" still works and is table.
Also, I cannot login to my blog. I am typing this entry from my server via RDP. I only managed to login once, but after that no more succes.
Typing in text on forums and facebook is also a drama. It starts a spelling checker and after a few words it is just dead slow. My workaround is typing in Notepad (yes still there) and copy/paste that
What do I think
I like the idea of moving to touch screens and I can see a business value in that, but without the touchscreen it does not make much sense to have tiles. Most people in a business operation only use few applications that they have open all day. Having sayd this it is harder to switch between applications, you can only use alt+tab. Alt+Start is dead.
What would make sense is to use the tiles for part of the application. For example put some ques on a tile rather than on the role center or have a tile with emails or a graph. That way you can use your desktop as a realtime overwiew, basically like sharepoint was meant to be when I first saw it over 10 years ago.
Is "try this at home". But don't use it for business yet. Even if it would be released like this, it does not add any value unless Microsoft finds a way to use the tiles from a business perspective