Using Navision 3.60A (North American)…
I am in the process of designing a custom statistics form that will be used as an Executive Overview. This form will be a ‘Multiple Tab’ form with a large number (in excess of 100) of FlowFields. These FlowFields will be stored on a single table and collecting data from a number of others.
I do know that once you exceed 100 FlowFields on a single table you cannot view the raw table data from the Object Designer, but I have a few other questions that I haven’t been able to get concrete information about.
1. Are there any other issues (Performance or otherwise) that I need to consider when designing this customization?
2. Will the Database Platform (C/Side or SQL) make any significant difference?
3. Is the performance based upon the data being calculated upon? A number of the FlowFields could be looking at a large amount of data, while others could be looking at little or no data.
Thanks
Darren
0
Comments
Yes, when you have so many flowfields in one table, when you try to run the table from object designer you would get a maximum flow field error. Moreover you are going to create so many keys in so many tables which would slow you system when you do a backup and restore. Also, i dont think you could have 100 flowfields in one table, i havent tried but its my guess.
Regards
Suresh.
Sounds like this might be the sort of thing that would be better accomplished by a report.
When you use a flowfield, if the fields are totalling numbers and you have to:
1 - add keys -> keys are not bad or evil, but every key in a table makes an insert / update / delete slower, along with making data retreival faster
2 - add SumIndex fields -> every sumindex field (using maintain SIFT index) you add creates a whole new (bucket) table if you are using the SQL Server version of Navision. Every level of 'SIFT levels to maintain' makes the bucket table bigger and bigger - so you should make sure that the information being used is worth all of the effort that you are putting the system through.
Reading between the lines on your post, if you are creating an 'Executive Overview' that is only going to be used once a month by a high level manager, then maybe you should consider an alternative - if this is going to be used daily then tread carefully - just make sure you minimize the SIFTs whereever possible.
-A
Maybe you can do something smart. For instance... if you make 1 flowfield that displays a saldo and you include a date flowfilter in it you can that dynamicly place filters on the field and place those values in a variable and show those variables on a form. You could then manually program the drilldown buttons.
This could decrease the number of flowfield you have to define and increase the speed of the system.
Maybe you should place your functional and technical design on the forum so we can take a look at it.
If it was hard to write, it should be hard to understand."
A very important issue when using many flowfields is to know how many records the tables will eventually contain. Things which work nicely on small number of records are frustrating when the record numbers go into the millions.
Kowa
If you are using a form with tabs and these tabs concern subforms, you could use a table for each tab.
Another option is to create a new table that you fill before/when opening the form. In this way you only bugger other users when opening the form.
Did nit try that but imho its worth to try it in that case