LLGLGen Pro maps duplicate named relationships when the following are part of the database schema. I know I can rename the duplicates but this is a headache when you have several fields that cause multiple duplications. I have provided a description of how to reproduce the problem with a simple example here. My question is: Is there any way to get the LLBLGen Pro to name them differently by default?

Example: 1. Start with the following 3 tables. Events Table SuperPersons Table Persons Table (Id is a foriegn key into SuperPersons Table) Causing inheritance.

1. In SuperPerson Table Add the following fields Id

2. In Person Table Add the following fields Id and create foriegn key from Id to Id in super person table.

3. In the Events Table Add the following fields Id Speaker and create Foriegn Key from Speaker to Id in SuperPerson Table Contact and create Foriegn Key from Contact to Id in Person Table

4. Create a project in LLBLGen Pro pointing to this database.

5. After you successfully retrieve the schemas then right click on the Entities column and perform the following 2 actions Add New Entities Mapped on Tables from catalogs and select all tables. Construct-target-per-entities

6. Try to Generate the code and you will get the following error: ERROR: Entity 'Persons' has multiple relations in the inheritance hierarchy which have the same field mapped onto them: 'Events'

Thanks for any help.

Billy Jacobs

This is by design, but let us investigate it deeply to see if we can do something about it.

The error you get is thrown by a checker precisely for this problem. It's very hard to fix this by default, because names have to be changed, but these can then be renamed to a name which isn't expected by the user, for example code which breaks. Also, which name to change: the name in the parent or in the child?

So when this error pops up, go into the editor for the entity and rename one of the names to a name you see fit.

Why wouldn't you name it based on the name of the field that the relation is created from?

So instead of Events, name them EventsByContact and EventsBySpeaker. That seems more logical and would eliminate this error and any confusion.

It is extremely confusing when you are looking at the Entities and then have to go back and forth between SQL Server Management Studio to look at the fields and relations and rename several of these yourself.

bjacobs wrote:

Why wouldn't you name it based on the name of the field that the relation is created from?

So instead of Events, name them EventsByContact and EventsBySpeaker. That seems more logical and would eliminate this error and any confusion.

You can do that, just set the correct pattern for the field in the project properties (which are inherited from the preferences when a project is created). This only happens in cases where people don't adjust the patterns AND have multiple relationships to the same entity from different subtypes. You can use macros to refer to startentity fields and endentityfields. See the description of the particular pattern or the manual (has the same description).

It is extremely confusing when you are looking at the Entities and then have to go back and forth between SQL Server Management Studio to look at the fields and relations and rename several of these yourself.

You don't have to go to sqlserver management studio, as you can see which relation a field is mapped on in the project explorer and also in the entity editor. The relation is then expandable to see the fields of the relation.

The main gripe with solving this on our part is that it's impossible to automatically fix it. The thing is this: say you have 4 entities, A, B, C and D. A and C have a relation with D, and a field is mapped onto that relation, called "Ds" in both. As they're not in the same hierarchy, no problem. Then you make C a subtype of B. Still no problem. Then you make B a subtype of A -> conflict. But... what to do? Which "Ds" should be renamed? A's ? Or C's ?

So the patterns in the preferences (and project properties, please set the preferences ones before a new project and in existing projects, set the properties as well, as they only inherit when the project is created).

You can link relations and fields-mapped onto them together in the project explorer and in the entity editor. I.o.w.: you don't have to go to any db management tool to get that info.

I modified the pattern to use {$EndEntityFieldNames}{$EndEntityName$P} and that solved my problem.

I am very impressed so far with this product. I have worked with several other ORM tools (Genome, NHibernate, Entity Framework, and one built by a co-worker at another company which was very good).

This is by far the best. I am a big supporter of Microsoft but this is far superior to the Entity Framework.

Thanks,

Billy Jacobs

Thanks Billy!

Glad you solved the problem too