Database RE - game breaking bug - need workaround

[MaXyM]

EA14 has a a bug reported a half year ago. Not fixed in neither v14.0 nor recent 14.1

While database initial reverse engineering (import from ODBC) works properly (with some glitches still, but it's another case), updating existing model process marks new elements with wrong attribute(s). It causes such elements to be not connected with the model, not supported by DatabaseBuilder therefore in next iteration of update process those are imported again and again.

Effectively it makes impossible to update existing model by changes already deployed to database.

Look at images below:

This image shows a table imported by initial import process.
You can see:

• its type is "Table"
• it has Database attribute in "Advanced" section
• look at casing of tagged values

Now, look at table imported by "Show differences.." feature

• its type is "Class" - you cannot change it to Table because there is no such entry in drop list
• it has Language attribute in "Advanced" section instead of Database one
• look at casing of tagged values. All is uppercase.

I attempted to compare attributes of those 2 objects using script debugger. I found that "Table" shown as type attribute comes from "MetaType" attribute, which is read only and comes from stereotype from an MDG Technology (see: https://sparxsystems.com/enterprise_architect_user_guide/13.0/automation/element2.html)

But since both elements has assigned "table" stereotype... I really have no idea what happens.

Sparx confirmed it as a bug, registered in their bug tracking system (under issue ID: 18048589) but I cannot wait years for the fix.

Do you think it could be managed anyway on my own? Ie fixing some data using scripting? If yes, how to do that?
I appreciate any help.

with regards

[Geert Bellekens]

Yes it is definitely possible to fix it using a small script. I saw a topic in the last few weeks related to that.
I think it also included some details about how to properly create table in EA (and not classes with «table» stereotype)

Geert

[MaXyM]

Thanx. Found it here
Tag value names remains uppercase but it seems it doesn't harm anything.

And now, since we have a workaround, Sparx will never fix the issue

BTW do you know if EA is able to import database objects into packages representing schemas? It always imports into Tables package (just imagine we have 50 schemas, with more than 1000 tables in total, and all tables land in single package, sorted by table name, because schema name is not visible in Project Browser). I wrote the script which moves objects to schema-related packages. Fortunately, v14 can find such moved object during subsequent REs. v13.5 wasn't' able to do that. So before running model update by RE, I had to move all objects back to Tables

with regards.

[Geert Bellekens]

Thanx. Found it here
Tag value names remains uppercase but it seems it doesn't harm anything.

And now, since we have a workaround, Sparx will never fix the issue

BTW do you know if EA is able to import database objects into packages representing schemas? It always imports into Tables package. I wrote the script which moves objects to schema-related packages. Fortunately, v14 can find such moved object during subsequent REs. v13.5 wasn't' able to do that. So before running model update by RE, I had to move all objects back to Tables

with regards.

Yes, that was the post I was referring too.

No, I don't think you can change anything to the location of the imported table.
Seems like it's worth a feature request to import the tables in subpackages based on the owner (is "owner" the same as "schema" in this discussion?)

Geert

[MaXyM]

I already reported it (August 2017) getting following response:

Unfortunately we can't think of any way to get around this limitation in the short term, other than moving all table objects into the Tables package before importing or comparing and then moving the objects back into their named sub packages.

We will look at correcting this limitation in a future release of EA.

As mentioned earlier, the promise has been kept. So since v14, the only work we have to do is to manually move imported objects into proper packages.

[Geert Bellekens]

I already reported it (August 2017) getting following response:

Unfortunately we can't think of any way to get around this limitation in the short term, other than moving all table objects into the Tables package before importing or comparing and then moving the objects back into their named sub packages.

We will look at correcting this limitation in a future release of EA.

As mentioned earlier, the promise has been kept. So since v14, the only work we have to do is to manually move imported objects into proper packages.

Ah, I see, I misread that part.

Geert

[MaXyM]

I was too quick with an enthusiasm.
No, RE  doesn't work correctly if tables are moved to other packages than original "Tables" one. In such case RE is not able to add missing constraints (ie foreign keys). RE recognizes missing ones, it displays them referencing to existing table objects, but execution of "Import from ODBC" function does nothing until both tables are in "Tables" package. Then everything works fine.

BTW, using scripting I've set StereotypeEx to 'EAUML::table'. It seems it works, but project browser shows 'EAUML::table' stereotype instead of 'table'. If I change stereotype manualy, then Project Browser shows shortened version of stereotype name. What should I set more? Could you please provide source code of your setStereotype() function?
Thanx

[Geert Bellekens]

Check if you have "EAUML::table" as a stereotype in the model stereotypes list.

If it is in there then it will nog resolve to this instead of the stereotype of the EAUML profile.
Deleting it from the list should solve that problem.

You can find the complete code on github:

https://github.com/GeertBellekens/Enterprise-Architect-Add-in-Framework
https://github.com/GeertBellekens/UML-Tooling-Framework
https://github.com/GeertBellekens/Enterprise-Architect-Toolpack

Geert

[MaXyM]

Thank you