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?
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)
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 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.