Synchronise Stereotype via API – odd behaviour

[ADucci]

Hi, I have created a function that can synchronsise an individual element (using the SynchTaggedValues (string Profile, string Stereotype) api function.

On my MDG Profile type, I have extended a requirement base class 4 times to create 4 new elements (lets call them A, B, C , D) – each of these elements have the same 4 tagged values assigned to them in the MDG  And the MDG has been working successfully for a while.
I am having an extremely strange issue, where if I delete the tags from existing elements (of stereotype A, B , C or D) and run the sync on each item.  Sparx returns all the deleted tags, except for element A in the above profile.
Does anyone have any clue, why the sync is failing on that one specific type, ( I can create new elements of that type or try with older elements of that type) however in all cases , the tags do not return to that specific element.

Really Confusing! 

[qwerty]

It might be a "wild" stereotype. Run a script to see the FQN of its stereotype (Element.SterotypeEx).

q.

[Nizam]

Check if there is a 'A' defined in 'UML Types' (local stereotypes list), this could cause this anomaly

[ADucci]

Thanks.

it all seems to be in order. there is no duplicate stereotype in the UML Types options, I am somehow thinking this might be "Wild" - I see that MDG TV's are also added to the t_xref table. Also that the t_xref record includes the tag details in the description
[myTag]D4F0310E-E861-2fe8-B98D[/myTag]-E17A6212FB46}  -- does anyone know what the Client and this embedded tag relate to in the database, I could not find anything?

Cheers

[Paolo F Cantoni]

Thanks.

it all seems to be in order. there is no duplicate stereotype in the UML Types options, I am somehow thinking this might be "Wild" - I see that MDG TV's are also added to the t_xref table. Also that the t_xref record includes the tag details in the description
[myTag]D4F0310E-E861-2fe8-B98D[/myTag]-E17A6212FB46}  -- does anyone know what the Client and this embedded tag relate to in the database, I could not find anything?

Cheers

What's the Name and Type of these t_xref entries?

Paolo

[qwerty]

Strange. TVs are usually not referenced in t_xref, only the element stereotype itself. Probably it would be best to contact Sparx support. They can look into your model (provided you are allowed to send them a copy) and find out more.

q.

[Mauricio Moya (Arquesoft)]

It is a known issue for me. When you have had several "version" of your MDG (profile), it is possible you have several elements, each one using a different version of the profile stereotype. When this is the case, you can note that t_xref table stores the reference to the GUID of the stereotype in which the element was created. So, it is possible to have different elements of the "same" stereotype, with different entries in the t_xref table, referencing the "same" stereotype but in different versions.

What have I done? Some of the above, but I have found it doesn't work 100% of times:

• Delete manually the stereotype entry in the Stereotype configuration window
• Delete the t_xref entries for the stereotype and the element (note there could be different entries in this table for the element, not concerning to the stereotype)
• Run your script that syncronize the tag values
• Restart the application, and if it is an shared database, make the other users restart the app.

[qwerty]

EA should not allow more than one version of a certain MDG to be turned on since it will only create chaos.

q.

[Mauricio Moya (Arquesoft)]

Sure, qwerty, but the t_xref table apparently stores an identifier of the GUID of the stereotype (or profile, or MDG, or something that is different for every publication of the new version of the profile). I suppose it could be useful if you return to a previous version of the profile, or to check if the version of the tag values of the element matches the tag values of the profile. (just guessing)

[qwerty]

Yes and no. There should be some method to hard switch/migrate from one version of an MDG to another one and not leaving both versions side by side in the same model.

q.

[Mauricio Moya (Arquesoft)]

I have a more complicated case similar to this, in the following post: https://www.sparxsystems.com/forums/smf/index.php/topic,39943.0.html