The ORM Foundation

I add Relational view as an Extension, thru the extension manager.

I get an 'Assertion Failed: Abort' message - for which I have a picture.

Pressing <Ignore> then gives a Visual Studio error that an "Index was outside the bounds of the array." and my model is closed (but VSTS keeps running.

If I <Abort>, then Visual Studio closes.

Hi Jim,

It might be better if these were filed under 'Technical Support' instead of on the main NORMA forums page. I think it is too much noise for the front page if there are a lot of posts here. 

Questions:

1. If you just add the relational extension without the view, what happens?
2. If it still asserts, do you get the same assert if you just extend the abstraction model (turned on automatically by the relational model, which is turned on automatically by the relational view)?
3. Can you try it on the February 2009 release (I'll post by Monday morning at the latest)?

There are detailed instructions in the readme on dealing with assert dialogs. You can just copy the text instead of taking a picture, but I'd still like to see the picture.

Thanks,

-Matt

Sorry for the wrong forum, and I don't know how to move it 

1. If I add the relational view extension (and remove 'Map to Relational Model' and 'Map to Abstraction Model') it still crashes.
2. If I add only 'Map to Abstraction Model' it does not crash.
3. This is with the earlier build.  I'll install the Feb 09 release and try again.

- Jim

You first scenario doesn't actually change anything (the Relational View requires the other two, so it turns them back on when the dialog closes), so the scenario I'm missing is 'Map to Relational Model' without 'Relational View'. This dialog is quite as smart as the generator settings, which blocks you from turning off depedencies.

I think you might have to send me the model file on this one. The only known crash at this stage is a cyclical identifer scenario (a directory structure, for example, where an entity is identified by a name and a parent entity of the same type).

Don't stress the forum, there are just too many places to keep track of. This is definitely a better location for this type of question, though.

-Matt

This is actually an abstraction model issue. The relational model is having a problem with garbage input data.

To workaround the problem, select the 'Service Level Agreement' objectification and either make the other uniqueness constraint preferred, or introduce a refmode on the objectified entity type (select the name, use the RefMode property).

There are several contributing factors here that combined to create the problem:

1. The 'IT Unit' entity type plays no functional roles except for the relationship with 'Service Level Agreement'
2. The objectification of the 1-1 means that an attempt is made to absorb all of the objectified fields into the identifying role (Business Unit)
3. IT Unit is a subtype of Business Unit
4. The double mandatory constraints on the 1-1

The end result is that the absorbption attempts to make Business Unit a part of IT Unit because of the identification choice (the identified table absorbs its identifier), and IT Unit is a part of Business Unit because of the subtype. The absorption algorithm needs to catch this cycle and relax one of the 'part of' relationships to a 'reference' relationship. Essentially, you have a cyclic structure with 1-1 relationships between Business Unit, IT Unit, and Service Level Agreement. Cyclic 1-1s are nasty.

We had some work on cycle checking done during a student project well over a year ago, but it was unfortunately never integrated into the system. I doubt there is an easy fix for this that covers the full cyclic scenario, but there might be an easier fix to catch the basic cycle where 'a is part of b'/'b is part of a'.

-Matt