Book a Demo

Author Topic: Bug? NotNull in column properties shows up as "Allow Duplicates" in query bldr  (Read 6000 times)

Richard Freggi

  • EA User
  • **
  • Posts: 498
  • Karma: +18/-7
    • View Profile
I'm writing a SQL query in query scratchpad to make a data dictionary for a physical data model that I have developed (EA build 1310 professional)
When I check/uncheck the "Not Null" checkbox in the column specification window and I run SELECT * FROM t_attribute, it is confused with AllowDuplicates result in SQL scratchpad.  If I check/uncheck the Not Null box, the "AllowDuplicates" result changes

Seems like the Not Null checkbox is not reported in the t_operation table

If I add a UNIQUE constraint to the column, it seems to be reported in the IsStatic attribute of t_attribute and it is also reported correctly in the t_operation table

Should I file a bug report?

Is there a reliable way to query EA for NULL / NOT NULL constraints for ERD/data models?

Thanks!

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Uhm, where is that checkbox?

q.

Richard Freggi

  • EA User
  • **
  • Posts: 498
  • Karma: +18/-7
    • View Profile
Enable database technology, in project browser add an element from toolset Database Engineering, Type: Table, right click on the table - Attributes - you can see the Not Null check box there, next to the PK checkbox.

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
As I see it t_attribute.allowDuplicates directly correlates with NOT NULL (1 = checked, 0 = not checked).

q.

Richard Freggi

  • EA User
  • **
  • Posts: 498
  • Karma: +18/-7
    • View Profile
Yes QWERTY, that IS the bug.  Because t_attribute.AllowDuplicates should relate to UNIQUE constraint, not to NOT NULL constraint. And t_attribute.IsStatic should not relate to UNIQUE constraint.  Seems like whoever was setting up the Database Technology MDG did not think it through completely.

Anyways I can kludge my queries using t_attribute.AllowDuplicates for NOT NULL and t_operation.stereotype with CASE...WHEN statements  (or whatever the hell the equivalent is in the putrid miasma of MS Access) for Unique/PK/FK. 

Another little Sparxian spice added to the boring life of an architect!

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Hmm, should it? I never got upset about inconsistent database design and where they used which column for what. I'll have a look where the unique ends up (that's all no longer in my head...).

q.

P.S: Right ahead: where is the unique constraint stored in the GUI?
« Last Edit: July 29, 2019, 07:09:32 am by qwerty »

Richard Freggi

  • EA User
  • **
  • Posts: 498
  • Karma: +18/-7
    • View Profile
In the GUI, UNIQUE is shown in Table detail - Constraints
In SQL scratchpad, UNIQUE can be accesses via t_operation.Stereotype (possible values are PK, FK, Unique and probably others, so need a CASE...WHEN statement to populate the data dictionary report)
« Last Edit: July 29, 2019, 11:21:14 am by Richard Freggi »

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
The mapping of column properties to the t_attribute columns is set in stone. It was done more than 15 years ago, and has that long of people using it. If you're writing queries directly against the database instead of using EA functionality that's one of the things you'll just have to live with.

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
When you want to get those UNIQUEs you need to go to t_xref. Look for rows like

XrefID;Name;Type;Visibility;Namespace;Requirement;Constraint;Behavior;Partition;Description;Client;Supplier;Link;

{CABE3372-DD93-4d05-9D35-15A9BABB4494};Stereotypes;operation property;Public; ; ; ; ;0;@STEREO;Name=index;FQName=EAUML::index;@ENDSTEREO;;{E0009633-E7E2-4849-AD3A-818EB8103A08};<none>; ;

That's how it is. Making a single query involving multiple tables is never fun. But once your hands are dirty...

q.