New post
AllAccepted answers
John Murray · May 15, 2017

As I understand it, the SU variant of the software is what's installed when you download from this page:

http://www.intersystems.com/library/software-downloads/

And as your error message states, this variant is barred from using a cache.key file to unlock further features.

I think you'll need a different software kit. AFAIK you'll be able to "upgrade" your current SU installation in situ without losing anything (provided you've followed the rules about how to name any of your own code that you store in %SYS).

Those of us with support accounts can download software kits via WRC Direct. But assuming you don't have such an account yet, the InterSystems folk who provided you with the evaluation key are probably the best ones to ask about how to get hold of the software kit you need.

John Murray · May 11, 2017

Have you considered implementing a Caché source code management tool such as Deltanji from George James Software, for whom I work? A Deltanji workflow can propagate code from one namespace to another, and can also propagate deletions. In other words, if you decommission a class in DEV, then propagate the now-decommissioned code object to TEST, the class will be deleted from TEST.

John Murray · May 11, 2017

If you don't mind working a the global level, here's a way of enumerating the classes that are stored in the default code database of a namespace:

USER>s namespace="%SYS"                                                          
USER>s impliedNamespace="^"_##class(%SYS.Namespace).GetGlobalDest(namespace,"^oddDEF")
 
USER>w impliedNamespace
^^c:\intersystems\ens171\mgr\
USER>s className="" f  s className=$o(^|impliedNamespace|oddDEF(className)) q:className=""  w !,className
John Murray · May 10, 2017

The page at https://download.intersystems.com/download/atelier.csp tells you how you can obtain the 1.1 beta provided you are using Atelier as an Eclipse plugin rather than as a standalone Eclipse-based application.

I don't know if the current 1.1 beta fixes this issue, nor if it will require a version of Caché greater that the current 2017.1 release in order to solve it (or indeed to work at all).

John Murray · May 10, 2017

Please explain what you mean by "unchecked".

As for "mapped", the following may give you what you seek.

For classname, e.g. %Library.String, this expression will return true (1) if the class is mapped from a database that is not the default code database for the current namespace:

##class(%SYS.Namespace).GetGlobalDest(,"^oddDEF",classname)'=##class(%SYS.Namespace).GetGlobalDest(,"^oddDEF")

John Murray · May 9, 2017

Settings stored in the XData block of the production class (e.g. values entered through Portal) trump any System Default Settins values.

In Portal there's this button to get you to a page that may help you understand what's going on:

For a long time I've complained that the Portal UI makes it too easy to override a System Default Settings value (which is namespace-specific) with a value that gets stored in the production class (which you might migrate from one namespace to another). Add to this the fact that Portal ignores source control when altering the production class sad