Quick Tip: Table Hierarchy Inconsistency Errors in Runtime Mode

David Meego - Click for blog homepageFollowing 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:

  1. 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.
  2. 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) Secure Link. 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.
  3. 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) Secure Link

Hope this information is useful to you.


Comments (4)

  1. David Musgrave says:

    Posting from Jivtesh Singh at About Dynamics, Development and Life


  2. David Musgrave says:

    Posting from Mark Polino at DynamicAccounting.net


  3. Raheel Ahmad says:

    Hi David

    Thanks for your contributions. I just want to know how the third method (duplicating the tables) actually work and what is the criteria for duplicating the tables i.e. do we have to duplicate every table used in the report (except our custom table).

  4. David Musgrave says:

    Hi Raheel

    You only need to duplicate the tables for which you want to add/change the table relationships for.  Then on the alternate report replace the original table in the hierarchy with your duplicate and then add the original table back as a one to one relationship from your duplicate.

    This makes sure that all the fields and restrictions using the original table still work, but also gives you control to add new relationships to your own tables.

    Hope this helps


Skip to main content