In this tutorial, it shows a ER relationship diagram, which I can't make show at all in the 2.6 LLBL I installed.

Also using my own database tables, I don't get the "Sub-types" drill down that the example shows. All my tables have the relationships defined as it shows properly in SQL Server.

What should I be looking at to make those appear / work?

quentinjs wrote:

In this tutorial, it shows a ER relationship diagram, which I can't make show at all in the 2.6 LLBL I installed.

Please add a better reference to the tutorials you're referring to. We don't use E/R models so I think you mean the hierarchy shown in the video tutorial: http://www.llblgen.com/pages/files/tutorialmovies/V2/Designer/mappinginheritance.html ?

Also using my own database tables, I don't get the "Sub-types" drill down that the example shows. All my tables have the relationships defined as it shows properly in SQL Server. What should I be looking at to make those appear / work?

As stated in the manual: that feature is auto-finding inheritance hierarchies based on pk-pk 1:1 relationships so the subtype has a 1:1 relationship with its supertype where the PK of the subtype is the FK. If your database doesn't have that, the feature can't find the hierarchies for Target Per entity, as that requires pk-pk 1:1 relationships.

You can create inheritance hierarchies manually, 1 hierarchy in a table, (target per entity hierarchy) with a discriminator column. Obviously this isn't detectable by the designer so you have to create these manually.

Otis wrote:

quentinjs wrote:

In this tutorial, it shows a ER relationship diagram, which I can't make show at all in the 2.6 LLBL I installed.

Please add a better reference to the tutorials you're referring to. We don't use E/R models so I think you mean the hierarchy shown in the video tutorial: http://www.llblgen.com/pages/files/tutorialmovies/V2/Designer/mappinginheritance.html ?

Also using my own database tables, I don't get the "Sub-types" drill down that the example shows. All my tables have the relationships defined as it shows properly in SQL Server. What should I be looking at to make those appear / work?

As stated in the manual: that feature is auto-finding inheritance hierarchies based on pk-pk 1:1 relationships so the subtype has a 1:1 relationship with its supertype where the PK of the subtype is the FK. If your database doesn't have that, the feature can't find the hierarchies for Target Per entity, as that requires pk-pk 1:1 relationships.

You can create inheritance hierarchies manually, 1 hierarchy in a table, (target per entity hierarchy) with a discriminator column. Obviously this isn't detectable by the designer so you have to create these manually.

Yes I was referring to the heirarchy in the tutorial video. To me this is the same thing as the ER as you show a ER diagram on the video. When you drilldown into the entity.

So perhaps I am confused but if I create 2 tables, and I put the parent PK as a FK in the child table, and this is the relationship, how is this different then the pk: pk you mentioned. To be honest I can not think of many cases where I would create 2 tables and the child table would have exactly ONE record for every parent. Generally there are multiples or I would just create a single table with all the fields in it.
Customer -> Products is a classic example of 1 to many.

BTW I do like the idea of thhe subtypes where based on the ID value you have different entities, that is cool.

To be honest I can not think of many cases where I would create 2 tables and the child table would have exactly ONE record for every parent. Generally there are multiples or I would just create a single table with all the fields in it. Customer -> Products is a classic example of 1 to many.

If you don't find the need for that, then you don't need inheritance.

But if you want t business case, I'll try to think of one for you. Here you go.

Suppose you have a Customer table with all Customer related fields. But your system requires a special treatement for VIP Customers, you need more fields only used for VIP Customers.

Then you have 2 options: Add these fields to the Customer table, and for normal Customers, these fields would be set to null. You might also need a field/flag to tell you if this Customer is VIP or not.

Another option is to move these extra fields into another table. And a record of a VIP Customer in the Customers table would have a corresponding record in the VIPCustomers table as an extension, to hold values for the extra fields. A normal Customer wouldn't have the extension record in the VIPCustomer record.

Thus to say for each record in the Customer table, there can be 0 or 1 related record in the VIP Customer table. (1:1) relation.

You can call this an inheritance relation, since a record in the VIPCustomer table inherits some attributes/values from the Customer table. You can also think of it as an extension to the original table.

But again, if you don't have the business case for it, then don't use it.

Additionally, I think you also confuse inheritance with normal relationships. Customer 1:n order isn't inheritance, it's a normal relationship and these are supported in the designer as 'relations'.

Inheritance works just as in C#/VB.NET: you have an entity E and you want to extend it with additional fields.