How to delete EnsEDI Globals?

Question

Question

Werner Noske · Jan 21, 2022

When I installed the IRIS 2021.2 Community Edition, I found some Globals, which seem to be set for the Intersystems Ensemble and DeepSee products. For me that is an annoying design error in those products and only confusing my developers.

As I do not want to use these, I tried to delete them, because they interfere in the list of globals mixed with our own Globals.

But for several of the EnsEdi Globals I get an error message telling me, they can't be deleted, because they are wrong.

Is there a way to get rid of them? Or do I have to wait for a new IRIS version?

Product version: IRIS 2021.2

Discussion (5)0

Log in or sign up to continue

Robert Cemper · Jan 21, 2022

Hi Werner,
The default of Namespace USER is to be mapped as Interoperability (aka ENSEMBLE) - enabled.
If you create a new namespace, deselect the Interoperability-Enabled checkbox.

You may of course also just delete Namespace USER and create a new one.
OR remove the mapping directly from iris.cpf.

2 0

Evgeny Shvarov · Jan 21, 2022

Hi @Werner Noske! It looks like you are trying to work on your project in the built-in USER namespace and database.

Don't.

USER namespace is for testing/demo purposes.

You are welcome to start a new clear database from scratch.

For example, you can follow this template that starts with a new clear namespace and database IRISAPP.

0 0

Evgeny Shvarov · Jan 21, 2022

But I agree - maybe we shouldn't deploy IRIS with a "prebuilt demo namespace" - a new namespace and database should go with the configuration setting. Tagging @Benjamin De Boe and @Andreas Dieckow

0 0

score 0 · Answer 1 · 2022-01-24T04:25:15-05:00

But for several of the EnsEdi Globals I get an error message telling me, they can't be deleted, because they are wrong.

Can you be more specific about what you mean with "can't be deleted"? If this is a <PROTECT> error because they are mapped to ENSLIB (as part of enabling the namespace for Interop as Robert described), you can just ignore that error in a try / catch block.

I'm not sure about the general application context but if you need to go through the full list of globals for your app, it may be be better to query the globals that are in your application's database (directory) using %SYS.GlobalQuery:DirectoryList() rather than all the ones that are visible in the namespace using %SYS.GlobalQuery:NamespaceList() or ^$GLOBAL. That'll avoid the issues with ^EnsEDI.

Note that if you are actually using DeepSee or interop (or more generally rely on any features that may be writing their own globals), just looping through the global list for this kind of operations is very risky. Most built-in IRIS features (besides DeepSee and interop, that is) will write to globals prefixed with ^IRIS.*

score 1 · Answer 2 · 2022-01-24T04:43:35-05:00

It is not a <PROTECT> error. Here are some examples which errors are shown:

EnsEDI.Description:

FEHLER #5002: Caché-Fehler: <SLMSPAN>zKill+4^%Studio.Global.1

EnsEDI.Description("X","X12"):("X","X12"):

FEHLER #5899: Dieses Global-Format kann nicht decodiert werden, da es falsch ist '^EnsEDI.Description("X"'.\n '^"X12"):("X"'.\n
FEHLER #5899: Dieses Global-Format kann nicht decodiert werden, da es falsch ist '^"X12")'.\n
FEHLER #5899: Dieses Global-Format kann nicht decodiert werden, da es falsch ist '^"X12"):("X"'.\n
FEHLER #5899: Dieses Global-Format kann nicht decodiert werden, da es falsch ist '^"X12")'.

I'm not using DeepSee and could delete the globals of this part without a problem.

Anyway - my problem is solved. I'll use a separate new database. Did not know, that is the actual standard.

I worked with Caché since 2003 for several year. And at this time it still was standard to just have the namespaces %sys for the Intersystems things and user for the application. So I tried to restart now the same way with IRIS.