Messages

1

General Board / Re: How to prevent automatic diagram rescaling?

« on: November 13, 2025, 09:40:42 pm »

Did this ever get resolved... it is basically limiting me to using EA for small and simple models and switching tools as soon as models get big and complex (in particular wrt deep hierarchy). It really should be possible to turn this functionality off when it goes past the point where it causes much more work than it removes

2

General Board / Re: SQL Queries, Connectors, and 'Find in Diagram'

« on: May 19, 2025, 08:50:13 pm »

I'll second PDC's desire for "first class" relationships. I could particularly do with a #CurrentConnectorID# after which I could do some of it myself. Including a "Find in Diagrams" for Connectors. Of course Geerts' Navigator would give me a route to this and more but IT say "no"  .
Aside: Many years ago I wrote the equivalent of Geerts' Navigator for (whisper it) another tool. I called it "TellMe" but Navigator is a better name (I guess that "Model Inspector" coves both the navigational and other data extraction aspects)

3

General Board / Re: SQL Queries, Connectors, and 'Find in Diagram'

« on: May 10, 2025, 01:48:48 am »

Perhaps this is something specific to Model Views? I use the following SQL for searching (not in a ModelView) a SysML model  for SysML connectors and determining if they have been "typed" (by Associations). Right click "Find in Diagrams" isn't greyed out, and works partially (it lists the diagrams the connector could be shown on, and if they actually show the connector it does select it on the diagram, whereas if the connector is hidden on the diagram it just opens the diagram. I should say I am using EA 16.1 so it is also possible things have moved on.

SELECT
   c.ea_guid AS CLASSGUID,
   c.connector_type AS CLASSTYPE,
   't_connector' AS CLASSTABLE,
   c.name As connector_name,
   c.PDATA2,
   a.name As association_name,
   c.direction,
   -- o_src.name as source_name,
   c.sourcerole,
   c.sourcecard,
   c.sourcestereotype,
   -- o_target.name as target_name,
   c.destrole,
   c.destcard,
   c.deststereotype
FROM
   t_connector c
LEFT JOIN
   t_connector a ON c.PDATA2 = a.ea_guid
WHERE c.connector_type = 'Connector';

Sadly I am not permitted to use Geert's EA Navigator, It would be really useful!

4

General Board / Re: Why is the new database file so much smaller after transfer using native XML?

« on: September 30, 2024, 08:01:18 pm »

Thank you both. I think I can answer my own follow on question to Geert having been searching since - EA doc may well use baseline and snapshot as synonyms but (counter-intuitively), t_snapshot doesn't contain the baselines, t_document does. So t_snapshot just contains the audit info and that is lost transferring by native XML.

5

General Board / Re: Why is the new database file so much smaller after transfer using native XML?

« on: September 30, 2024, 07:22:51 pm »

Did you check the diagram images?
We have configured diagram images to be automatically (re)generated when the diagram changes.
This setting is necessary when using WebEA or Prolaborate as they don't generate diagram images themselves.
These diagram images are also stored in the database (QEA) but not transferred, probably to save bandwidth and they can always be regenerated in the new repository, even in a batch process in the background.

Thank you - Would you know how I can tell (if one model has diagram images and the other does not), Cheers, Ralph

6

General Board / Re: Why is the new database file so much smaller after transfer using native XML?

« on: September 30, 2024, 07:18:55 pm »

Did you check the t_snapshot table? (baselines and auditing info)

I can imagine that transfer via native xml doesn't transfer t_snapshot.

Geert

Thank you Geert, I clearly didn't look closely enough at the diff - you are quite right, the t_snapshot table has been cleared. The puzzling thing is that I did "ask" both models whether they had baselines and they both gave the same list - if the smaller file has 0 records in t_snapshot how come it has baselines? Baselines and snapshots are the same thing aren't they, much of the Sparx documentation seems the use the terms interchangeably ("Baselines are snapshots of a repository Package taken at a point in time. These snapshots are stored in a format called XMI"). Opening the smaller file I have just asked about baselines, selected one and ran the diff - this does seem to be working (hasn't finished yet) so presumably the snapshots are still there even when there are no records in  t_snapshot! Cheers Ralph

7

General Board / Why is the new database file so much smaller after transfer using native XML?

« on: September 27, 2024, 11:36:46 pm »

Hello,
I've needed to do a full project transfer from a remote database twice now, and as luck (and my poor memory) would have it I did it using "Full Project Transfer via Native XML" the first time and "Full Project Transfer via Connection" the second time. Call them 1.qea and 2.qea. 2.qea is four times bigger than 1.qea and this surprised (and worried) me. I then did another "Full Project Transfer via Native XMI" from 2.qea to give 3.qea and 3.qea is a quarter of the size of 2.qea. I did a project compare between 2.qea and 3.qea to try to see what was missing - but the results were identical. I also did a quick inspection of both models - they look the same to me - and asked each about some baselines - again they seem the same.
I'm at a loss. The EA Help (for the Native XML transfer) says that "Note: This data will not be exported as a part of the Project Transfer: Audit Logs, Image and Image-maps of diagrams, HTML Pages of Linked Documents" but I'm really surprised that this would result in a fourfold decrease. Could it be something to do with past use of replication (the model has "remove replication" greyed so its not current if so)?
Any advice gratefully received. Being defensive/risk averse my gut reaction is to only use the bigger files as they are less likely to have anything missing!
Cheers,
Ralph

8

Bugs and Issues / Instantiating Association Blocks in SysML

« on: July 12, 2023, 08:17:23 pm »

First time post (please be kind!). In particular apologies for the very textual nature of this post - I made pngs of bdd and ibd but haven't yet found out how to attach them (Attachments and other options only gives me other options!)
I'm modelling a system and one aspect I need to model is the comms network aspect. I've done this many times in many tools but this is my first time to need to do it in depth and at scale in Sparx EA. My full method would be quite an essay but one aspect of it is the following simplified example (the real thing has generalisations, loop back associations and more in the mix). Here are steps to show my dilemma:
On a BDD create two classes "RS232 Transmitter" and "RS232 Receiver", plus an association block between them, naming the association "RS232 Cable" and association block "RS232 Characteristics" (EA appears to treat the two as separate model elements with separate names). Give the Association Block a Value Property "baud rate" (You'll need a Value Type I'd call "Baud rate").
Now create one more Block called "My System" and a composition to "RS232 Transmitter" and another to "RS232 Receiver"
Create an IBD for "My System" and Synchronize the Structural Elements to get the two parts. Draw a connector between them. Right click the connector and chose "Advanced>Set Connector Type" and in the resulting dialog select "RS232 Cable". Now I'm stuck - I should now be able to set the baud rate (a value for the value property) on this connector - ideally directly (according to specification they are one not two model elements) but I would settle for having a third property node for "RS232 Characteristics" that must be linked to the connector in a similar way to the way EA handles the definitions. There is something called "Connector Property" that looks like it might the the thing I need but does not seem to work as expected (and the documentation I can find on it is minimal and not helpful). Either way I would want both to be able to show this on the diagram AND have the underlying model match.
My workaround: Create Tags (and give them values) on the connector (and don't bother with the association class) and show the tag values using a call out note. There are all sorts of reasons this isn't really satisfactory. I'll only cover one: the set of characteristics we might want a communications link to have is not fixed, baud rate is a bad example here as it is pretty ubiquitous even if we more often quote "bandwidth" on faster technologies, basically I am pointing out that using a tag (and stereotype if you want to be more compliant) mechanism is the wrong abstraction level.