Powershell Repository.Execute NullRef exception

[Guillaume]

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

[Geert Bellekens]

Do you mean in version 17.2?

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

Geert

[Guillaume]

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" ?

[Eve]

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.

[Geert Bellekens]

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

[Guillaume]

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?

[Eve]

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.