Model generator and like-named PK columns

Originally Posted 23 July 2014, 4:28 pm EST

  • Originally Posted 23 July 2014, 4:28 pm EST

    I'm evaluating ActiveReports 8 Server, and have a question about model generation.

    When I generate a model from a SQL Server database that has identically named PK columns in multiple tables, the model generator infers a PK/FK relationship between those tables on those two identically named ID columns. In my case, this is wrong - there is no such relationship. There IS a PK/FK relationship between columns with different names, with an FK relationship defined in the database, and the model generator correctly follows the FK. So the model generator creates two relationships between a pair of tables, one correct and one incorrect.

    For example:
    table PARENT:
    RID int not null identity (1, 1) /* PK */
    NAME varchar(MAX)

    table CHILD:
    RID int not null identity (1, 1) /* PK */
    NAME varchar(MAX)
    PARENT_RID int not null /* FK PARENT.RID */

    results in a model with 2 relationships between PARENT and CHILD: one on PARENT.RID = CHILD.RID, which is wrong, and one on PARENT.RID = CHILD.PARENT_RID, which is right.

    My database has many tables, and fixing all the generated relationships will be a pain. Is there a way to tell the model generator NOT to match on like-named columns in different tables?
  • Reply


    First of all, please accept my sincere apologies for the delay in response.

    I understand your requirement and have forwarded it to the concerned team (with tracking id : 175255). I will get back to you as soon I hear anything from them.

  • Reply

    Hi Stephen,

    I would like to understand more about your use case and determine how it is different to our other customers. Based on experience and feedback from our customers, they have seen that though their databases have a lot of tables and Views to store/aggregate data, they do not use many of them in the Data Models that they create for their business users.

    The use case behind Data Models is primarily to simplify the data structures from the technical DB Schema to a non-technical, business oriented model which the business users can relate to. An important best practice is to ensure that only data that user will need in his/her reporting is available in the data model. This prevents the model to seem overwhelming to the user and promotes usage of the report designer for self-service reports. You can imagine what business users will think if they see hundreds of Entities in their Entity Tree when they open the designer.

    Given that the Data Model generator is relying on the technical structure of the DB schema, it cannot make the leap to define the business structure exactly for every use case that end users have. So the customization step for the data model is expected. The customization required is more or less based on the complexity of the DB schema.

    I look forward to understanding your use case in more detail so we can suggest the best course for your users.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels