Is there a simple way to get an overview of al forms and their relation to the underlying tables. I want to find out which fields of which tables can be accesed by which form? I’m fairly new to Navison.
In short - NO. Read this: Navision architecture
However, in some cases Table and it’s corresponding “form” (actually “page” in latest versions) share the same name, but this is mostly true for master data as Items, Vendors, FA, and like.
Only if you have developer access to forms (pages), then you can check which table each form (page) is linked to, but ways doing it differ in different versions of Navision - you have not mentioned which one you use.
Thnx for the quick reply: for the sake of argument: what if I had such a developer access :), how can I check (in an easy way) the above mentioned relation. I We make use of Nav 2009 R2.
Many endusers have granule 7120 Form Designer included in their license, it was common way to buy additional Forms for customization. This allows to modify LAYOUT of Forms, but not the code in them.
Up to and including version 2009 the Classic Client was the development environment. If you have that granule 7120, you can open any form in Classic Client and hit Ctrl-F2, it will open in design mode. (If it does not, it means you do not have that granule).
Then, hit Shift-F4, and form properties window will open (there is a button for that in toolbar, too, but hard to explain which one here in writing).
Among many other there is SourceTable…
I hopefully consider you’ll do this is test environment, not production - although there is an option NOT to save changes when exiting the design mode (by simply closing the form), it’s very easy to mess the things up, especially, if one is not familiar with NAV development.
Thnx again. But what if a form gets its data from more then a single table?. Currently I’m trying to create a matrix table (Excel) in which all the rights per role are documented. I got as far as an overview of all the permissions which these roles need on numerous tables to excecute their daily tasks. As common practice dictates, i defined these permissions on tables, leaving all other objects “open”. Users can only access the nessecary tables using forms. I now want to find out if specific table datafields can be edited (which shouldn’t be) by using a form. Because I know the tables which have more then read rights on them, I now want to find out which forms are related to these tables. It’s just the opposite way of what you described.
Well, here we dive deeply into NAV architecture. Looks like I should move this thread to Technical forum…
Let us stick with the term FORM, once it was started so, but the same is true for PAGES.
A form can have only ONE table it is based on (or none).
In case with multiline document forms, main form is linked to {xxxx} Header table, but lines are actually a separate subform, linked to {xxxxx} Lines table. See Purchase Invoice - there are actually TWO forms - 51 and 55.
NAV is not a normalized database, it has very high redundancy. Therefore, once the data is entered in an Invoice, ALL necessary fields are duplicated from numerous other tables into Header/Lines, instead of being only referred. e.g. Item Description is also a field in {xxxx} Lines table(s), not only in Items table
Besides, NAV has so called FlowFields, which are not physically present in table, but behave like “normal” fields when put on a form. An example could be Inventory field in Item table - think of it as a rather complicated SUB-SELECT statement from Item Ledger Entry table, if we can speak in SQL terminology.
All that said, you have started a Goliath job, in which no-one up to now has succeeded, although many have tried. A bunch of tools have been made in different times and for different NAV versions, but none was even close to perfect.
One more NAV specific issue I can add on top of all already said - user sometimes must have INDIRECT UPDATE rights, that is, he can’t edit field when it’s put somewhere on form, but CODE running under his account needs to update that some field for normal workflow, usually when posting something.