Performed a quick test just now using 10.2.01 + F103, no problem to create a relationship between an entity and its subtype. Would you mind sharing the SQLite db or an export of your model with us?

Hi Henk, thanks for the fast reply. In the meantime, I just created my own testset to isolate the problem, but right now, it works as expected. As I used a non-db entity for the testset so far, I will continue with the investigation.

looks like the subentity EMPLOYEES_REPORTING is damaged for whatever reason. So let's close this topic.

further check: looks like a length problem of entity plus model name.   In my testset, I extended the subtype name in my working example until I got: [APERSON_90123456.RELSHIPTEST => APERSON_9012345678901234567890.RELSHIPTEST] As Relationship Relationship could not be created [error=-100001] Data validation error [APERSON_90123456.RELSHIPTEST => APERSON_901234567890123.RELSHIPTEST] As Relationship Relationship could not be created [error=-100001] Data validation error [APERSON_90123456.RELSHIPTEST => APERSON_901234567890123456.RELSHIPTEST] As Relationship Relationship could not be created [error=-100001] Data validation error [PERSONS_TREATED.RELSHIPTEST => APERSON_901234567890123456.RELSHIPTEST] As Relationship Relationship could not be created [error=-100001] Data validation error   reducing the entity name to APERSON_9012345678.RELSHIPTEST made it work again. In my original context, it looks the long model name has to be blamed.

The message "data validation error" is a valid message in this situation, but not very helpful. The "data validation error" pops up in more locations/situations and still needs to be made more specific for the context it appears in.

Personally, I think that a lot more of the messages would be improved by adding the object (and where appropriate it's value) causing the error to the message by default  "Data validation error (U_RGLAB.UCRELSH - APERSON_901234567890123456.RELSHIPTEST)" at least gives you clues as to where and what data might not be validated.... 

Hi Henk, in 9.6.04, I have no problems to declare the relationship EMPLOYEES.NORTHWIND_SQLITE => EMPLOYEES_REPORTING.NORTHWIND_SQLITE as shown in the EXPORT file: <OCC> <DAT name="UTIMESTAMP">2016-11-11T14:24:01.25</DAT> <DAT name="U_GLAB">EMPLOYEES</DAT> <DAT name="U_VLAB">NORTHWIND_SQLITE</DAT> <DAT name="U_RGLAB">EMPLOYEES_REPORTING</DAT> <DAT name="U_RVLAB">NORTHWIND_SQLITE</DAT> <DAT name="U_DELC">RES</DAT> <DAT name="U_KSEQ">1</DAT> <DAT name="U_FIDX">N</DAT> <DAT name="U_INTEGRITY">F</DAT> <DAT name="U_OPTIONAL">F</DAT> <DAT name="U_FLABS">REPORTSTO</DAT> <DAT name="U_ARITYMAX">0</DAT> </OCC> but in U10 i get some irritating validation errors which do not allow this relationship. I think this has all specifications of a bug, hasn't it?

Hi Uli, We just had a quick check using the names you have used in your example. It's not so much caused by the length of the entity names, but the length of the generated description that is visible just above the line that represents the relationship. The current maximum length of that description in the Database is 64 characters. Indeed, if the sum of the length of both entity names (full name, including the period and the suffix) exceeds 64 characters, you can't create the relationship. Yes, that's a bug (31454). We already have an existing requirement to not automatically generate a description for new relationships. We'll add your report as a reason to expedite that requirement.

Hi Henk, what is the reason to create this description in the first place? As it just repeats the PKs, it is not a useful information at all, just filling the database field with redundant info. In all the years, we used descriptions on relationships to provide additional info if necessary. And it was easily visible under all the empty descriptions; especially if you sorted on description or you report on relationships without empty descriptions.