Levels of C/SIDE Development Access

Olds

Is anybody aware of how the increasing levels of access to C/SIDE effect a developers ability to customise?

Once your solution contains Form, Report, Dataport, and Table Designer, how far can you customise Navision before you need Application Builder/ Solution Developer?

Essentially, what capabilities do Application Builder/ Solution Developer granules give you beyond the object designers?

Thanks

Olds

kine

SD licence - access into Codeunits... posting etc.

wesleys

Olds wrote:

Is anybody aware of how the increasing levels of access to C/SIDE effect a developers ability to customise?

Once your solution contains Form, Report, Dataport, and Table Designer, how far can you customise Navision before you need Application Builder/ Solution Developer?

Essentially, what capabilities do Application Builder/ Solution Developer granules give you beyond the object designers?

Thanks

Olds

I just barely got application builder a month ago. From a former software developer's (not navision, C++) standpoint, being asked to administrate navision without application builder is a lot like having to do any job while blind with no tools and one arm. You can do it, and there are great consultants that can help you do whatever you want, but it gets lame asking for every tiny little thing, especially if it's a very simple one line of code solution.

Codeunits aside, being able to work in the C/AL code behind forms and tables is wonderful.

jreynolds

Application Builder does not provide access to protected tables (e.g. ledgers) while Solution Developer does. Therefore, with Application Builder you will not be able to modify or create objects that require insert, modify, or delete permission to any of these tables.

Olds

Thanks for the help everyone,

Coming from a software development background myself I can see that there may indeed be a need to progress past the object designers.

I know that the difference between Application Builder and Solution Developer is that you can't access write-protected tables unless you've gone the whole hog and purchased Solution Developer. The question is, what consitutes a write-protected table - is it every table that ships with Navision core modules and granules, or is it certain tables (ones that only relate to core financial functions for example, that modifying may have a negative effect on core functionality)?

wesleys, having gained Application Builder access, how much do you find you are able to do in terms of customisation before restrictions are imposed?

Once again thanks,

Olds

Olds

Sorry jreynolds, had posted my reply before receiving yours, appreciate that information.

It seems that Application Builder will be capable enough to provide me with the access I need for the customisation this project requires, but i'd be interested if anyone has found this level of access still too restrictive.

Much appreciated,

Olds.

wonmo

With application builder you cannot modify any data in protected tables (eg. Sales Invoice Header, Purchase Invoice Header) whereas with the Solution Provider license you can. Also, with the App Builder license you still have to purchase objects for internal use whereas with the Solution Builder license you do not. Furthermore, you have the capablility to create objects in restricted object number ranges with the Sol. Provider license.

wesleys

Olds wrote:

wesleys, having gained Application Builder access, how much do you find you are able to do in terms of customisation before restrictions are imposed?

Olds

I wouldn't consider any thing I've done with the application builder to this point to be considered large or even medium in size or difficulty. I do simple things like customize "onlookup" events to automatically filter out blocked items from the item list that would normally appear during an Item lookkup. Or, creating code behind buttons that will open typical windows file browse windows. I don't think I would be allowed to mess with any fundamental accounting tables, I would rather not anyway. With that in mind, the only restriction I've come accross, is a couple of codeunits that supposedly provide examples of importing XML are not available to me to look at.

I hope that gives you a better view of what you can and cannot do.