Book a Demo

Recent Posts

Pages: [1] 2 3 ... 10
1
Now I'm afraid I'll have to make some kind of workaround with a direct database connection. Not exactly ideal, especially in large corporate environments.
Yeah, that's not ideal. You know what's worse? Bypassing the security measures that are set up to prevent random changes in a database where the people who set up those restrictions have no visibility that it's happening.

- Update or create information that are not available in the API
- Quicker execution time by 10 times or more compared with API methods, making the script usable (e.g. I've seen scripts running time dropping from over 60 minutes down to 3 minutes)
Send in a request for the API changes you need detail exactly what's needed and why. I won't make any assurances that they'll be allowed though.

Is there a way to restore this function whilst adding some level of security?
I can't see any way that it will be allowed.
2
Hi Eve,

I understand the issue of having this method potentially identified as a vulnerability, however I share Geert's feedback i.e. this method is needed in many cases to address the following:
- Update or create information that are not available in the API
- Quicker execution time by 10 times or more compared with API methods, making the script usable (e.g. I've seen scripts running time dropping from over 60 minutes down to 3 minutes)

Is there a way to restore this function whilst adding some level of security?
3
I'm indeed running the latest build and I confirm it is supported in earlier builds (I successfully ran it using a 16xx build)
Minor correction. It was never supported, it was never documented.

I've personally commented many times here when someone suggested it here that it's unsupported and may be removed without notice.

Now it has.

It's come up a lot as a vulnerability just because it exists. Enough that we had to do something about it.
Hi Eve,

I understand that. For me personally, I have used it only in those cases where I had no other option.
This was either because something was not exposed in the API, or because the API was way too slow to be usable.

I've sent an email to Sparx support a while ago, listing all of the use cases of Repository.Execute() (and also the use cases of querying the t_sec*** tables), asking for alternatives.
It's been a few weeks now, but I haven't gotten any response yet.

If there is an alternative, I'm the first one to use that, instead of Repository.Execute.

Now I'm afraid I'll have to make some kind of workaround with a direct database connection. Not exactly ideal, especially in large corporate environments.

Geert
4
Automation Interface, Add-Ins and Tools / Re: Powershell Repository.Execute NullRef exception
« Last post by Eve on September 30, 2026, 08:23:50 am »
I'm indeed running the latest build and I confirm it is supported in earlier builds (I successfully ran it using a 16xx build)
Minor correction. It was never supported, it was never documented.

I've personally commented many times here when someone suggested it here that it's unsupported and may be removed without notice.

Now it has.

It's come up a lot as a vulnerability just because it exists. Enough that we had to do something about it.
5
Hi Geert

I'm indeed running the latest build and I confirm it is supported in earlier builds (I successfully ran it using a 16xx build)
Hopefully this "feature" will be removed in the next build  ;)

I have both EA 17.2 and 16.1 installed on the same machine. I wonder if there's a way in PowerShell to force using EA16.1 when creating the object "$Repository = New-Object -ComObject EA.Repository" ?

6
Do you mean in version 17.2?

That is one of the new "features" of 17.2. Repository.Execute() doesn't work anymore.

Geert
7
Hi,
I'm working on a Powershell script that uses EA API. It works well except calling the Repository.Execute method to run INSERT/UPDATE/DELETE queries doesn't work.
I get the following exception:  CategoryInfo          : OperationStopped: (:) [], NullReferenceException

Everything else like Repository.SQLQuery work fine

Is there a workaround to get the Execute method to work ?

Thanks
8
Hi,

We've tested this in Enterprise Architect 17.2 using several combinations of diagram fields, generating both individual Model Documents and the combined Report Package, but couldn’t reproduce the missing figure caption.

Could you confirm which EA version and build you’re using, and check whether the issue still occurs with the latest available build?

If it persists, could you share a minimal template that reproduces it and the output format you’re generating (DOCX, RTF or PDF)? That would help us compare the setups more closely.

If your team is looking to improve how your organisation uses Enterprise Architect, you can get in touch with us to learn more.
9
Thank you!
10
For the default diagram font, use Start → Appearance → Preferences → Preferences → Diagram → Appearance → Default Fonts. Note that a diagram-level font can override your user default.


You can add EA’s standard legend from Toolbox → Common → Diagram Legend. However, that legend is primarily intended for appearance conventions such as colors and line widths. It does not provide entries for UML connector-end symbols such as the filled Composition diamond.

For a printed notation key, the practical workaround is to create a small legend graphic showing the required symbols and insert it into the diagram, or construct a small manual key using sample connectors and Text/Note elements.

If your team is looking to improve how your organisation uses Enterprise Architect, you can get in touch with us to learn more.
Pages: [1] 2 3 ... 10