Can I use the same license for Nav2009SP1 and Nav2009R2?
Normally yes!
But if your maintenance agreement with Microsoft expired before 2009 R2 was released, then not. So I suggest that you try it by installing NAV 2009 R2 as a “standard alone” and try to import your NAV 2009 SP1 license.
Thank you. It works.
I noticed that anyone with Microsoft Nav developer’s license will always have full access to any database of the version involved. How do I control developers on my network? No matter the level of control they can always have access, possibly do something wrong and delete the audit trail. Is there a way i can prevent the developers on my network from being able to delete the audit trail entries.
Thank you
dimeji
Hi Dimeji,
The short answer to this question is: Never upload your development license directly into a database!
But then again, if your developers have SUPER permission, then they would still be able to temporary upload the developer license and do whatever they want. So if the database are live/production databases (and not development databases) then if you don’t trust them, then don’t give them SUPER permission. What I’ve always done is to have separate development, test and production databases. Then I’ve given all the developers full access to the development and test databases, and only a few fully trusted developers SUPER on the production database. Naturally this way only these fully trusted developers with SUPER permission are able to upload changes to the production database, but that’s really the only way if you don’t trust the rest!
I think i should then take one of the following options: write a code to track the audit trail table such that the entries therein are constantly being moved to another table in another instance. This will help to track what everyone is doing. Even if a mischievoues user hit the system, he wouldn’t know that the content of the audit trail is being copied to somewhere else. What do you think?
Hi Dimeji,
I know I’m late to the party, but I do have an opinion about your last question. I don’t think that the idea you mentioned is necessarily feasible, or even necessary. You’re trying to give yourself a good way to recover from an event that causes data loss or corruption. I think that the suggestions that Erik gave you on how to structure your development environment (separate dev, test and production servers), exercising obsessively strict control over your NAV license file and over user credentials (as Erik suggested, being progressively strict on user rights as you move from DEV to TEST to PROD databases), implementing and proving a disaster recovery plan for your NAV systems, including frequent backups that you’ve proven can be restored, maybe maintaining a hot-swappable NAV Server, using mirrored sql servers, etc. are proven standard methods for improving your odds of recovering from a disaster.
And just a couple of observations, if you don’t mind. The term “audit trail” is more of an accounting concept than it is a data attribute. Within the domain of the NAV program and individual granules, you’ll see a core financial accounting application, with General Ledgers, Sales, Receivables, Inventory, Fixed Assets, Payroll, Income Statements and Balance Sheets. The accounting concept of an audit trail is permeated throughout all of these granules in the application. Without going into a long and boring exposition on what an audit trail is, I would like to take a second to point out, within the NAV domain, what it isn’t. In the plan you described in your last post, you thought you might
"… write a code to track the audit trail table such that the entries therein are constantly being moved to another table ".
The reality is that there is no such single table in NAV. While it’s true that a key component of NAV’s audit trail involves data, it also involves data architecture, business rules, operational procedures, and security, none of which can simply be copied to another server with sql scripts.
And yet another option, to help you better understand how your system is being used, and who’s doing what, is a feature in NAV called Change Log. Once you’ve configured it, you will be able to see what data is being changed, when, and by whom. It’s a great tool that has helped me out of a jam on several occasions.
I know that’s a lot of information. I hope you find some of it useful.
Hi George. Thanks for your contribution.
It is possible for a super user with a developer license to delete the content of the change log. How do we prevent this? An issue happened in my office recently, that someone deleted the entire content of our job ledger entry table. After that he either deleted the entries in the change log, or disable the change log before carrying out the act so that the system will not record whatever he must have done on the system. How do i prevent this from further occurrence?
Use better judgment when handing out super credentials? Once you’ve given a user the keys to the kingdom, you have no automatic control over what the user can do. Your only control is to not give super credentials. Sure, you can write code to prevent records from being deleted, and a user with super credentials can modify the code to permit it.
If you’re having this kind of issue, the cause and solution has less to do with NAV than it has to do with those who are responsible for its care and feeding.