Hi,

I'm having some trouble with inheritance in the following situation:

I have two tables A and B. There is a relationship between the two tables. In the generated code class B inherits from class A. Both tables have a field named revision which can't be null.

When I set the revision property on class B the save function fails, because it tries to insert a null value in table A for field revision. It seems that the property revision on class A is not set.

How can I solve this?

Thanks, Remco.

If a field has the same name, it's 'overloaded'. If you go into BEntity's code and browse to the property Revision, is it declared 'override' or 'virtual' ?

After you've set myB.Revision = 10; (example), is myB.Fields[BFieldIndex.Revision_AEntity].CurrentValue also 10?

(and be sure to use the latest runtime libs: rightmousebutton on ormsupportclasses.dll -> version tab)

Hi Frans,

I checked the things you wrote and this is the outcome:

The property is declared "overloaded". The value "BFieldIndex.Revision_AEntity" in fields stays 0 and is not updated. I use the latest version of the runtime. downloaded it yesterday

Some things are changed in our code now and we use the fields property to set values. I understand in that way we need to find all fields that have "revision" in the name. We undid the inheritance and now are going to solve it in another way.

Thanks for the quick answer

Remco.

Remco wrote:

Hi Frans,

I checked the things you wrote and this is the outcome:

The property is declared "overloaded". The value "BFieldIndex.Revision_AEntity" in fields stays 0 and is not updated. I use the latest version of the runtime. downloaded it yesterday

Some things are changed in our code now and we use the fields property to set values. I understand in that way we need to find all fields that have "revision" in the name. We undid the inheritance and now are going to solve it in another way.

Friday-itis hits again... I of course meant override, not overload.

So the property for the Revision field in B should be defined as an override of the property in A. If that's not the case, the field isn't marked as an overriding field and it then isn't 'linked'. This means that in B, you have both A and B's fields in the Fields object. If a field is overriden, they're linked together, so if you set B's value, the value of A's version is also set and vice versa. This makes both values to be set without a problem.

So as the field of A isn't set in an instance of B when you set the revision, they don't seem to be linked. I'll setup a testcase here to see if I can reproduce it.

I also would recommend to avoid setting field values through the Fields object, but use SetNewFieldValue() on the entity.

Reproduced. My PK fields are linked, but my Revision fields aren't, so the revision field for A isn't set after I set the revision field on a B entity. This is a TDL interpreter error, the fields are properly linked to eachother in the project file.

Looking into it.

(edit). Indeed an issue with the Foreach FieldToLink statement. THis will be fixed a.s.a.p.

Although I have to say: if non-PK fields are overriden in a hierarchy of target per entity, you're storing redundant data. 'Revision' in A is automatically part of B through inheritance. So it doesn't belong in table B. So removing Revision from table B will make it work again and gives you a better model as well. (see that as a workaround for this issue).

Ok, reading back the design documents I came to the conclusion that it's better not to fix this. Currently PK fields of a subtype are linked to the PK fields of the supertype, though non-PK fields which override a supertype field aren't linked, and it's also better not to do that, as it doesn't make sense: it shows that a subtype's table contains a duplicate field which is already in the entity through the supertype's table.