Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Paolo F Cantoni

Pages: [1] 2 3 ... 536
May I ask which term? (But in general, I know what you mean)

Just to be clear the correct term is Foreign Key Constraint!  As such. there is NO requirement that the name of the constraint bears any relationship to the (possibly many) attributes that comprise it[1].

They are correctly named as Foreign Key Constraints because they are a constraint on the origin table that the values of the attribute(s) in the origin table must be the values of a uniqueness constraint (typically implemented as a primary or alternate key) of the destination table.  There is no requirement that the origin attributes be a key in the origin table, although Inversion Indexes (NOT Keys) are often implemented to make it easy to traverse joins from the destination to the origin table across the Foreign Key Constraint.

Hopefully, that should settle the matter.


[1] Indeed, many RDBMSs generate random names for them.

Use the right terms and you'll be able to better understand things.

(It only took me thirty years to realise I'd been using the wrong term all that time!)


Abstraction: the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances.
I took Gerard as meaning that he wanted to show the database (system/environment) at different levels of detail.  That's not the same as abstraction, but we often use the term not quite correctly.
Perhaps Gerard could clarify?

By the way, it seems to me that ANY reverse-engineered database model with Foreign Key Constraints is an example of using BOTH attributes and associations simultaneously.


Bugs and Issues / Re: Link Element Features
« on: Today at 12:40:15 am »
Yeah, link to element features is only allowed in custom style; I've noticed that too.

As Geert implies it has always been thus.  EA has some (to us mere mortals) anomalous restrictions on line drawing.  Not just link to element feature.


Not entirely sure we are on the same page here but it is worth exploring. If you take the last diagram of your article,

I am also not sure why you and qwerty have concluded so quickly that I am trying to miss the 2 approaches you described in your replies.

You have an association between Order and Product. It does not appear, from the diagram, that any attributes have been used to set the MemberEnd properties of the association. Are you suggesting that attributes should not be used to set the MemberEnd properties of the association?

Product.Category has a type of ProductCategory and Order.MoneyAmount has a type of MoneyAmount. I don't have a problem with this concept. But the relationship between these Classifiers are not associations, they look like dependencies, and, in addition, using cardinality, in this case, doesn't make too much sense.
Hi Modesto,
FWIW, in these types of cases, I fall back on a UML "first principle" - which used to be explicitly stated in earlier versions.  "A named association end IS an attribute."  Consequently, we allow either or both (but only if the association end is named).  Along similar lines, we render many of EA's "hidden" relations as arcs.  Thus the typing (a form of classification) relationships you mention, we might implement as realization relationships with the attribute selected as the source with a "link to Element feature" via a bit of "black magic".

It's unfortunate that EA doesn't allow you to apply consistent functionality across the various types if you really need it.

NOTE: if you are generating code, using both may not be acceptable to the current implementation of the code generator.  But my point still applies, if the first principle is valid, then the generator should handle it.

So as you can see I differ from qwerty and Geert, but we don't generate code using EA in our models.

Does that help?

Automation Interface, Add-Ins and Tools / Element Names and Notes
« on: January 17, 2022, 02:48:59 pm »
We have the ability, with our Shapescripts to apply additional names to an element besides those in the Name and Alias fields (via the use of the Label subshape).  We also have the ability to render more than one shape when in non-rectangular (i.e. icon) mode.  However, while all this is useful, the one thing we CAN'T do at present is to show the Notes field in non-rectangular mode.  Neither can we shoe a name other than the name or alias fields in rectangular (i.e. compartment) mode.

Does anyone know how we could accomplish either being able to use an additional name in rectangular mode or render the notes (preferably in rich text) in non-rectangular mode?



I know I can place the same object on more than one diagram.

However, can I represent the same object in different diagrams to levels of abstraction?

So, in one high-level view can show a database deployment as one simple 'square' object but elsewhere in the model show that as part of a more detailed deployment...perhaps showing it as a Server/OS/DB.

The ideal would be to 'drill' from one level of abstraction to another.

Any hints?


Hi Gerald,
Have a look at the Composite Structure Diagram.  That's essentially what it is there for.  However, you need to decide how you're going to model what you are seeing.  The single object "Database" CANNOT be composed of a Server / OS/ and Database.  You could say the Database is composed of Server Software, OS Software and DB Software.  Or Sever hardware, OS Software and DB Software.   That is, a DB cannot be composed of a DB.

If you have more questions, just ask.


Automation Interface, Add-Ins and Tools / Re: v16β - new .EAPX schema?
« on: January 13, 2022, 07:55:42 pm »
Not experienced that exact problem but I am finding that some eapx files open okay and some I get DAO.Engine [0x80004005] cannot open a database created with a previous version of the application.
Haven't had time to look into it.
All the eapx files open okay with V15.2.
Thanks, Sunshine,

Good to know we're not alone!


Automation Interface, Add-Ins and Tools / v16β - new .EAPX schema?
« on: January 13, 2022, 03:29:06 pm »
We have a number of .eapx files that are generating a
"DAO.Database [0x00000d0e]

Invalid Memo, OLE, or Hyperlink Object in subquery 't_object.PDATA2'"
error under v16β (both versions).

Searching the Net doesn't bring up anything as to what the error means.

We have (in the past) "hijacked" t_object.PDATA2 and this has caused NO problems up to and including v15.2.

Since null is a valid value for PDATA2 we ran a test making the column null for all objects.  The problem persists and the upshot is that NO diagrams show ANY objects (whether PDATA2 is null or not).

Did we miss a schema change between v15 and v16β?  If not, what can this error mean?  Anyone else seeing this?


BTW: in the past, we have had error messages from EA that are spurious - that is the error is NOT what is claimed.  Unfortunately, as in this case, the actual problem can't be determined since the message provides no direction for the investigation.

General Board / Re: Can't enter "em-dash" in title...
« on: January 12, 2022, 09:25:45 am »

dash en-dash em-dash

and only dash is accepted. Neither subject nor this text here accepts any "non-ascii" dashes.

Please try again. If you come back to this error screen, report the error to an administrator.

Thanks q,
It was my convention, in the past, to use the em-dash following the version number in titles.  Those posts are now corrupted.
See v16β – Purge of Element doesn’t “clean-up” after itself for example...


General Board / Re: BIAN experiences?
« on: January 11, 2022, 10:36:48 pm »
I'm going to steal that one; love it  ;D

It even sounds like a buzzword someone in the sales department would come up with



General Board / Re: Multiple use of elements in diagram
« on: January 11, 2022, 07:01:40 pm »
I have previously suggested a (to my mind relatively simple) solution to the problem in the thread: Real t_diagramobjects for Virtual Connector Ends - please, please, please? over two years ago.

I have seen no indication that this would not solve the various issues surrounding the multiple use of elements in diagrams.



You can't change the UML relationships for the UML types.

Neither the restriction nor the warning are new.
I knew that neither the restriction nor the warning were new, what was new was I had the system Window open on startup (it's normally not visible) so I saw the message.  (Side note, from a UX point of view, perhaps the System window should be forced open if not visible when such errors are detected) 

It now explains why what I was trying to achieve didn't work!

As you might see from the code snippet, I was trying to fix the lack of the Quicklinker having an Extension relationship between a Stereotype and a Metaclass (which seems to have been fixed in v16β - can anyone confirm?) and also to allow a "See Also" relationship between Stereotypes.  How can I achieve this (in v15.x)?


When I started up one of the repositories we have this morning, I got the message:

"Ignoring metaconstraints for Stereotype from profile: <our profile>"

Is "Stereotype" the affected element[1]?  Or is the affected stereotype not shown?


Our profile does have a metaclass called "Stereotype" as shown below.
Code: [Select]
<Metaclass name="Stereotype" notes="">
      <metarelationship metaclass="UML::Extension" constraint="StandardProfileL2::Metaclass"/>
      <stereotypedrelationship stereotype="PrIME::SeeAlso" constraint="Stereotype"/>

Pages: [1] 2 3 ... 536