License confusion and NAV development

(0) Share

Report

Posted on by Royce Lithgo

In our license I see this (and some other stuff not important)

Name                                                                  Amount
----------------------------------------------------------------- ----------
8100 Codeunits (10)                                                       20
8200 Tables (10)                                                          10
8350 Pages (100)                                                         100
8400 Reports (100)                                                       100
8750 XML Ports (100)                                                     100

With this license i have been able to make a minor customisation to the Item Card to enable a field which is normally not visible. I did this via Object Designer and created a FOB file to export my change from our DEV environment to UAT.

When I try to import the FOB in UAT (which has the same license), I get an error saying "You do not have permission to modify records in Object table.") I have been informed that i would need application builder or solution developer license to resolve this. Either of these license requires us to switch to Perpetual license and pay a lot of money upfront. Given the uncertainty of NAVs roadmap, it does not seem like a wise decision to pay all this money now and then perhaps be forced to migrated to D365 in a few years or so.

Is it really true that while i am able to modify objects with our current license, i cannot migrate those changes via FOB import unless making a considerable investment for application builder? I could of course make the changes manually in each environment, but that would be a really poor change management process.

*This post is locked for comments

I have the same question (0)

All responses (5)

Answers (1)

Brad_P 1,549 on at

Like (0)

Report

The error seems to indicate a permission error. Did you check the account permissions in UAT? Importing of objects does not require a "development license". This would be the approach if importing NAV cumulative updates.

Was this reply helpful? Yes No
Verified answer

epernst 1,122 on at

Like (1)

Report

Hi Royce,

So you have been able to create and run customization's in your DEV environment.

And now when you import them into UAT, running the same license then you get this error?

I assume that you also have the same permissions in both DEV and UAT?

And that you're a DBO of both databases also?

The only situation you need application builder or solution developer license is if you want to create new codeunits, or customize the table triggers. Item card customization's does not. If you exported it as a FOB file, then there should be no issues when importing otherwise.

So don't really understand what you mean about having to invest in much more or upgrade. This is a matter of setting up permissions. In my 25 years working with Navision, I only had 2 or 3 customers ever buying the "full package" for in-house usage. Nobody is forced to buy it to be able to use NAV.

Btw. except for a delay in the releases and a terrible name change in sight, then what uncertainty do your have about NAV's roadmap? No changes in regard to on-premise vs. cloud.

Was this reply helpful? Yes No
Alexander Ermakov 28,096 on at

Like (1)

Report

Dear Royce, it is actually more simple. In order to do developments, you need a developer's license. You can reveal hidden fields on the page, but you are not able to develop and design standard objects. Here has been a good thread on that:

stackoverflow.com/.../ms-dynamics-nav-development-licensing-basics

community.dynamics.com/.../206660

Was this reply helpful? Yes No
Royce Lithgo on at

Like (0)

Report

[quote user="Erik P. Ernst"]

Hi Royce,

So you have been able to create and run customization's in your DEV environment.

And now when you import them into UAT, running the same license then you get this error?

I assume that you also have the same permissions in both DEV and UAT?

And that you're a DBO of both databases also?

The only situation you need application builder or solution developer license is if you want to create new codeunits, or customize the table triggers. Item card customization's does not. If you exported it as a FOB file, then there should be no issues when importing otherwise.

So don't really understand what you mean about having to invest in much more or upgrade. This is a matter of setting up permissions. In my 25 years working with Navision, I only had 2 or 3 customers ever buying the "full package" for in-house usage. Nobody is forced to buy it to be able to use NAV.

Btw. except for a delay in the releases and a terrible name change in sight, then what uncertainty do your have about NAV's roadmap? No changes in regard to on-premise vs. cloud.

[/quote]

I think you have given me the answer. I suspect the account that was setup for me by our Partner to connect to the Database in the development environment does not have the necessary access level to perform the FOB import. I will follow this up with our partner.

Re: NAV's roadmap, have a look here: community.dynamics.com/.../235740

Was this reply helpful? Yes No
Royce Lithgo on at

Like (0)

Report

[quote user="Alexander Ermakov"]

Dear Royce, it is actually more simple. In order to do developments, you need a developer's license. You can reveal hidden fields on the page, but you are not able to develop and design standard objects. Here has been a good thread on that:

stackoverflow.com/.../ms-dynamics-nav-development-licensing-basics

community.dynamics.com/.../206660

[/quote]

Alexander, there are many different levels of development, from simple things like adding fields to tables / pages etc. to customising core code. For our needs, purchasing both perpetual license and solution developer (if that's what you're suggesting) is overkill.

I would hope that with the delivered license we can make basic changes. I do see that we would have limitations with no access to Codeunits, and if we needed such access, i am hoping application builder would suffice. Can't see why the average customer would need a full solution developer license.

Was this reply helpful? Yes No