Author Topic: Double stereotypes  (Read 2738 times)

Michael Mangelschots

  • EA Novice
  • *
  • Posts: 14
  • Karma: +0/-0
    • View Profile
Double stereotypes
« on: September 21, 2021, 05:17:00 pm »
I'm trying to migrate our Oracle repository to a SQL Server repository and I encounter issues because apparently we have double stereotypes. In Oracle the primary key on t_stereotypes (stereotype, appliesto) is case sensitive, while in SQL Server the primary key is case insenstive.

We have 5 doubles:
Code: [Select]
Sterotype               AppliesTo         Description        mfenabled    metafile    style                ea_guid    Visualtype
Application             Component         Application        0                                            {843C0C...   
Application             component         Application        0                        <STYLE fill="...    {5E4AB0...
document                Artifact          document           0                                            {54D888...
document                artifact          document           0            (BLOB)      <STYLE fill="...    {BD5E9D...
Functional requirement  Requirement       UML Profile Notes  0                        <STYLE fill=..."    {05B213...  Profile=D1A4427B-1;
Functional requirement  requirement       UML Profile Notes  0                        <STYLE fill=..."    {BD439D...
TimingEvent             Event             TimingEvent        0                                            {D94638...
TimingEvent             event             TimingEvent        1            (BLOB)      <STYLE fill="...    {69A58C...
Update vessel           InformationFlow    Update vessel     0                                            {3C1687...
Update Vessel           InformationFlow    Update Vessel     0                                            {C14E60...

Any suggestions on how to can decide which I should remove?

thanks

Michael

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 11251
  • Karma: +415/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Double stereotypes
« Reply #1 on: September 21, 2021, 06:02:13 pm »
You can check which ones are used by querying the t_xref table.

Geert

Modesto Vega

  • EA User
  • **
  • Posts: 624
  • Karma: +18/-8
    • View Profile
Re: Double stereotypes
« Reply #2 on: September 21, 2021, 06:03:31 pm »
It is possible to have case sensitive databases in SQL Server. It is just a matter of changing the database collation, CS on a SQL Server database collation means Case Sensitive whilst CI means Case Insensitive.

Please see https://docs.microsoft.com/en-us/sql/relational-databases/collations/collation-and-unicode-support?view=sql-server-ver15 for more details.

I will make the SQL Server database case sensitive before trying anything else.

Michael Mangelschots

  • EA Novice
  • *
  • Posts: 14
  • Karma: +0/-0
    • View Profile
Re: Double stereotypes
« Reply #3 on: September 21, 2021, 06:19:29 pm »
It is possible to have case sensitive databases in SQL Server. It is just a matter of changing the database collation, CS on a SQL Server database collation means Case Sensitive whilst CI means Case Insensitive.

Thanks, but I also tried transferring the database to file, and that failed for the same reason. This makes me believe that EA doesn't want double stereotypes. And so I think it would be best to remove them.

@Geert, thanks, I'll try that.

qwerty

  • EA Guru
  • *****
  • Posts: 12334
  • Karma: +347/-287
  • I'm no guru at all
    • View Profile
Re: Double stereotypes
« Reply #4 on: September 21, 2021, 10:22:34 pm »
Try running a consitency check first and see if that cures it.

q.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 11251
  • Karma: +415/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Double stereotypes
« Reply #5 on: September 21, 2021, 11:50:19 pm »
Try running a consitency check first and see if that cures it.

q.
Always a good idea, but for this case I'm pretty sure it won't do anything.

Geert

Modesto Vega

  • EA User
  • **
  • Posts: 624
  • Karma: +18/-8
    • View Profile
Re: Double stereotypes
« Reply #6 on: September 22, 2021, 05:35:56 pm »
Does a DBMS to DBMS project transfer between 2 case sensitive databases give you the uniqueness error?

If you are doing a DBMS to File and them a File to DBMS transfer, you are most likely getting the error on the DBMS file because data is transferred to an access database which is case insensitive.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 11251
  • Karma: +415/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Double stereotypes
« Reply #7 on: September 22, 2021, 06:00:17 pm »
Does a DBMS to DBMS project transfer between 2 case sensitive databases give you the uniqueness error?

If you are doing a DBMS to File and them a File to DBMS transfer, you are most likely getting the error on the DBMS file because data is transferred to an access database which is case insensitive.

Sure, but regardless, there's no need to have those duplicate stereotypes in the model.
It's not like there is a difference between a "Component" and a "component".

So it's a good thing to clean this up, even without the database transfer.

You should be able to remove the duplicates using Configure | Reference data | UML types, but I'm not exactly sure how EA will handle the elements that already use such a stereotype.
My gut feeling is that this won't be a problem, but I would definitely test it first to make sure.

Geert

Modesto Vega

  • EA User
  • **
  • Posts: 624
  • Karma: +18/-8
    • View Profile
Re: Double stereotypes
« Reply #8 on: September 22, 2021, 09:00:33 pm »
Does a DBMS to DBMS project transfer between 2 case sensitive databases give you the uniqueness error?

If you are doing a DBMS to File and them a File to DBMS transfer, you are most likely getting the error on the DBMS file because data is transferred to an access database which is case insensitive.

Sure, but regardless, there's no need to have those duplicate stereotypes in the model.
It's not like there is a difference between a "Component" and a "component".

So it's a good thing to clean this up, even without the database transfer.

You should be able to remove the duplicates using Configure | Reference data | UML types, but I'm not exactly sure how EA will handle the elements that already use such a stereotype.
My gut feeling is that this won't be a problem, but I would definitely test it first to make sure.

Geert
I agree, it is a good idea to clean this up.

Having done this before with a previous version of Sparx (v13), my recollection is that before deleting the UML Type, as you described, I had to find and clean up all the elements using the duplicated stereotypes. From memory, without doing this Sparx magically reintroduced the duplicated stereotypes into UML Types, possibly each time an element containing a duplicate stereotype was accessed. I don't know if they fixed this with version 15.

Michael Mangelschots

  • EA Novice
  • *
  • Posts: 14
  • Karma: +0/-0
    • View Profile
Re: Double stereotypes
« Reply #9 on: September 27, 2021, 05:13:55 pm »
I can confirm that running the project integrity check did not remove the double stereotypes.

Furthermore, I noticed that any stereotypes that contains uppercase characters in the AppliesTo field, when I make any changes to them, are duplicated upon saving. The new record has all lowercase. (on Oracle DB) So I will also update the database and force all AppliesTo to lowercase.

update:
After doing the above, I also had to remove the Audit log (850k records). Running the project transfer I first received an out of memory error, and after moving to more powerful computer I received an internal server error. After removing the Audit log the transfer was successful. Although it still took 2h45m, even though our repository isn't that big.

We will now test if the removal of the stereotypes has much impact....
« Last Edit: September 27, 2021, 09:14:27 pm by Michael Mangelschots »