Sparx Systems Forum
Enterprise Architect => Bugs and Issues => Topic started by: Michael Mangelschots 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:
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
-
You can check which ones are used by querying the t_xref table.
Geert
-
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.
-
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.
-
Try running a consitency check first and see if that cures it.
q.
-
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
-
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.
-
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
-
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.
-
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....