previous article
Database queries are defined by multiple objects in arcplan. Apart from the object with the query itself, other objects define the columns, rows and filter settings. In so doing, they are able to influence themselves, as well (performance arrows, selection-based filters…)
Linking the objects for a database query is defined by the connection of the objects in the connection mode. Arrows are drawn. Even though the objects are frequently set up together, the place or the order of the objects is irrelevant for the function. These objects may even be located on various reporting levels.
Time and again, there are connections between multiple levels in reports, where the filter objects are located on document level and the actual data query is located on one of the background levels due to further editing. Moreover, it is quite frequent if objects are moved and rearranged in the course of (further) developing the report. In this context, not all related objects are moved together all the time.
This distribution of the objects across the report is technically possible and does not entail any functional disadvantages at first, either, but should nevertheless be avoided.
The reason is primarily technical. Even though the connection works, the connecting arrows over multiple levels are not displayed in the connection view upon the activated display of the arrows.
This is demonstrated in the following screenshot:
Here, a data query is located on level 1. The data query is here apparently defined only by the currency filter ([<Filter_Currency>]) apart from the row and column object. However, this is not correct in this case, as the two other filters ([<Filter_Period>] and [<Filter_Customer>]) are taken into account in the query, as well, namely on the reporting level; this, however, is not displayed. Deactivating the display of arrows in the connection mode, as shown in the following screenshot, will make this visible.
Here, all five objects defining the data query are now displayed by the little red arrow in the lower right object corner. This, however, can only be recognized if the objects are in the visible field. If this is not the case, there is the danger that one wrongly assumes that there are only three objects relevant to the query, and that thus, the report is misunderstood.
In order to avoid this, the display of the number of connected objects (green circle 1, bottom right) and also of the arrows in the connection window (green circle 2, top right) are good functions in order to recognize whether there are any further objects relevant to the query on other levels, i.e. which objects are relevant. The display of the number of related objects shows the number of objects connected to the selected object. This applies both to the database connection and to the formula reference. In case of a data query, it shows the number of all objects relevant to the query. If they exceed the number of visible objects, and if arrows are not visible in arrow mode, then objects relevant to the query are located on other levels. The arrows in the connection window (green circle, top right) are only used in order to find these. Thus, all related objects are highlighted, while the display focuses on the respective object.
All this is quite long-winded and very time-consuming. As in case of doubt, this needs to be done for every data base query in order to ensure that nothing is missed.
Conclusion
Thus, we see that connecting arrows across multiple levels work technically, but severely impede the overview. While it is possible, it is quite long-winded to recognize the exact functionality and the correlations in these cases. While this is still manageable in the development phase with one developer in case of smaller reports, it may already cause problems in case of larger reports.
If one adjusts the reports after a few months by oneself, or if a colleague takes over the report, it may become very time-consuming and prone to errors.
Thus, connecting arrows across multiple levels should be avoided. Basically, in the best case, all connected objects should always be positioned in close proximity to the data query and be designed with uniform layout. This should also be part of the model approach taken by everyone. The time invested at the outset in this context is quickly gained if it becomes necessary to understand the report again in the course of adjustments/developments or transfers.
