Quick Tip: Table Hierarchy Inconsistency Errors in Runtime Mode
Following on from yesterday's post: Quick Tip: Creating Dexterity System Variables, I want to cover a related issue.
This is when a Dexterity developer is creating a report (either new or alternate) which will display data from newly added tables. To get the data to show on the report the developer creates a table relationship from an existing Dynamics table to their newly added table.
Can you spot the problem yet?
This report works perfectly when in Dexterity Test Mode, but once the chunk is created and installed in Runtime Mode, the report fails with the following error:
Table Hierarchy Inconsistency Error.
The problem is caused by the same situation as described in the previous System Variables post. Table Relationships are not a separate resource, but are included in the table definition. So adding a Table Relationship to an existing Dynamics table will never work as it will never be included when resources are extracted during the chunking process.
This is discussed in the following Knowledge Base (KB) article that I wrote:
The solution is to use other methods to get your data onto the report. For example:
- Create your own Report Writer User Defined Functions (Dexterity functions with the name prefixed by "RW_"). The functions can then be used on an alternate version of the report. This method is only valid when there is a one-to-one relationship between the tables.
- Use triggers on the 6 functions; rw_ReportStart(), rw_ReportEnd(), rw_TableHeaderCurrency(), rw_TableHeaderString(), rw_TableLineCurrency(), and rw_TableLineString() as described in the KB article: Useful functions for developers to use instead of creating alternate reports in Microsoft Dynamics GP (KB 888884)
. This method can avoid alternate reports by using modified reports instead and is only valid when there is a one-to-one relationship between the tables.
- Duplicate the original Dynamics table definition so that it has a Resource ID > 22,000 and add your table relationships to the duplicate and use the duplicate on the report instead of the original. You can now add the additional table to the report. This method can work when there is a one-to-many relationship between the tables. You should also include a one-to-one relationship from the duplicate table back to the original, so that the original can be added to the report as well.
Note: If using the Report Writer User Defined Functions approaches, please look at the following KB article for how to avoid performance issues: How to improve the performance of user-defined Report Writer functions in Microsoft Dynamics GP 9.0 or in Microsoft Great Plains (KB 920830)
Hope this information is useful to you.
David