Expanding on the earlier answers by Eduard and Robert:

A process will not be able to switch to a namespace (e.g. with Do $ZU(5,ns) or ZNAMESPACE ns or Set $NAMESPACE=ns or via Do ^%CD) unless the user holds the Read privilege on the database resource of the default globals database associated with that namespace.

To read about this, see the "Namespaces" subsection of this doc section.

When you GOTO you never come back.

With a DO you do.

Doc for 5.0 is available at http://docs.intersystems.com/documentation/cache/cache5docs/

At the bottom of that page I found this:

Using the Caché GBLOCKCOPY Routine —  This article describes the basics of running GBLOCKCOPY to copy globals.

The link is to a PDF. One of the use cases in the PDF is as follows:

Reclaim unused space in a database
If a large global is created then killed in a database, there may be a large excess of unused space in the database. This space can be removed by copying all the globals in the database to a new one, and then replacing the old database with the new database.

That's what I think you need to do. It sounds like you used GBLOCKCOPY to copy to a namespace in an existing database rather than to a fresh empty database.

Of course, you will need enough disk space to have the smaller new database alongside the big database until you have completed the copying.

Are you able to use the beta of Atelier 1.1? See https://community.intersystems.com/post/atelier-11-beta-updates-%E2%80%9...

Please show us the code that is writing the output. Also, tell us what your $zversion variable reports, and what platform you are running Cache on.

CHARWIN might be useful. But if you're extending an existing terminal-based application you may want to work the way the existing code does. And if you're starting a new application, is a terminal-based UI still the right way to be going?

If you are working directly with globals (as your example seems to imply) you will have to iterate appropriately through your global, test the relevant value, and kill any node that matches.

Be sure that you also understand that a KILL will delete any subtree of the node you kill.

To efficiently maintain the sort of uniqueness you seem to be describing (i.e. for any Y there must be no more than one X for which $list(^myglobal(X))=Y) you will probably need to maintain a cross-reference (a.k.a. index) such as ^myglobalX("index1",Y)=X and check for the existence of a record here before saving a new record.

Here's a way of discovering if your license includes the iKnow feature:

USER>w $system.License.GetFeature(11)
1
USER>

A return value of 1 indicates that you are licensed for iKnow. If the result is 0 then your license does not include iKnow.

See here for documentation about this method, which tells you that 11 is the feature number for iKnow.

Regarding namespaces, these are created in Portal, not in Studio. See this documentation.

Gigi, you tagged your question "Developer Community", but I think that's primarily intended for posts about DC itself. Using one or more of the Ensemble-related subtags, e.g "HL7", might help your post.

Jeffrey, is your answer still accessible to you from your "My Account" page?

When I look at your page's "Answers" tab the first (i.e. most recent one) points here:

https://community.intersystems.com/post/overwrite-file#node-433196

Since I'm a DC moderator it may be the case that I can see it but you (or other ordinary members) can't.