When I start a fresh installed IRIS or a Container I always find Interoperabiliy (aka. Ensemble) mapped to namespace USER.
Is there any utility to remove this mapping by a click ? unmapping it global by global, routine by routine, Package by Package is just a boring exercise.
To be clear: I look for a utility inside IRIS.
The external utility is obvious: Notepad (or any other text editor) - clean iris,cpf, - restart IRIS It's fast, it's efficient, but it's really hardcore.
I have a CSP page that is supposed to show some user info (Full name and some other properties retrieved from AD)
I am unable to get them outside of %SYS namespace using Security.Users class. Is there another mechanism to do that, or I am using Security.Users class incorrectly?
Hi,
We have been upgrading our application to ensemble 2016.1.1. I have moved my data to a particular namespace which i have created and now in management portal i have been getting an error message "namespace does not support Ensemble". Please give solutions to resolve this issue.
Currently, we have an application running in one namespace ("Database B") that has globals and routines mapped to another database ("Database A"). After enforcing clean up on Database A, we found that 90% of the disk is free. We would like to compact Database A and release the unused space. However, we are running OpenVMS, which seems to be the issue.
For databases consisting of only globals, we are able to use ^GBLOCKCOPY; however, we need to ensure that the routines and mappings are also copied.
I have made a complete copy of our test namespace into a secondary test namespace. Thereby we can test with our current EHR version and our soon to be deployed EHR version simultaneously. However, we have a number of saved searches within the Message Viewer that we would like to have available within our secondary namespace. Is it possible to export the saved searches within the message viewer?
Is there a way to run code on another machine? Of course, all authentication info is known. I know only about RemoteResultSet but that seems to be query specific.
I need an example of what I need to "map" to have a common dashboard defined so it will visible/usable in multiple namespaces.
I have created a dashboard in "SAMPLES" (namespace and database) and I would like to have this dashboard be accessable/useable from a 2nd namespace, but I'm not having any success in doing mappings (global/package/routine/data) to be able to get DeepSee to be able to see/display the dashboard.
We want to isolate the storage of our CCDAs from our HL7 V2 data, but keep them under the same namespace. From my understanding, I should create a new database then store those classes related to CCDAs in that database. Is this the correct approach?
Sometimes global mapping of the same globals can be defined in different ways. E.g., I need to define it for 3 globals ^qAuditC, ^qAuditLog, ^qAuditLogC from the same database named APP-NOJOURN. Which approach should be better from the performance point of view?
1) qAudit* => APP-NOJOURN (one record in global mapping table) or
2) qAuditC => APP-NOJOURN qAuditLog => APP-NOJOURN qAuditLogC => APP-NOJOURN (three records in global mapping table)
Can I please check if anyone know why the data base resource is created differently when creating a namespace after specifically selecting it to use the default resource %DB_%DEFAULT?
I created a namespace and when creating the DB I selected the option to use the default resource
When the namespace creation was complete , database is using a new resource instead of the default.
is there a way to copy namespace mappings from another namespace to a new namespace programmatically with a command?
When using management portal there is an option to choose an existing namespace to copy the mappings from, I'm basically looking for the equivalent from command line / COS.
I have a Zen Page with tablepane which has a datasource in a different namespace to that of the Zen Page. When the page is run, no data is returned and the tablepane is not populate, even though the rerferenced table contains dat.
Currently, namespace Alpha is configured to use database AlphaDB as its global database. How would we go about having namespace Alpha configured to use database AlphaDB for its global database except where global ^Customers(CustomerId) has a CustomerId greater than 10M, which we would like to have it redirected to database BetaDB.
In other words, ^|"AlphaDB"|Customers contains all customers between 1 and 10,000,000; and ^|"BetaDB"|Customers contains all customers greater than 10,000,000. Any help would be appreciated.
I'm trying to enable an existing namespace to be Ensemble enabled by doing the command do ##class(%EnsembleMgr).EnableNamespac($namespace,1), but I'm still getting the error message. Is there something that I'm missing?
I've attempted to reboot the server and even went incognito to see if it was a caching issue, but I'm still not able to create an Ensemble production in that namespace.
I have a need to dynamically create a web application definition in a namespace using ObjectScript. I am having trouble finding a cache class or routine that let's me do this.
Had an empty Ensemble namespace (interoperability enabled) which the customer had requested renaming before beginning development, so was wondering about best practice to achieve this.
I have multiple namespaces in a Cache environment say NS1 & NS2. I want to add some restriction so that a routine running in the NS1 should not access any resource(global/routine) belongs to namespace NS2.
The above restriction need for few of the clients only, so we do not want to write any custom logic in code.
We are looking for some solution provided by Cache where we can restrict the namespace access.
Have enabled LDAP for our numerous , Ensemble, IRIS and cache instances with many namespaces. All is working fine and the ldap logins work.
But have noticed that the first instance that the user logs into the namespace is assigned to that user, but when that user than logs into another instance the default namespace from the first login is still there and doesn't update to the new namespace.
So this doesn't effect the ldap login but is now effecting the terminal logins where the user is now getting access denied.