Can you show us the code of your while loop, in case DC members can suggest performance improvements?
- Log in to post comments
Can you show us the code of your while loop, in case DC members can suggest performance improvements?
Per this article of mine, it's unwise to expose the value of %session.Key
Sean, I assume the </h1> tags are supposed to be </h2>
And if any of the ZWRITE output includes the string </pre> then all bets are off, right?
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.
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 !,classNameThe 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).
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")
Interesting to see that $$$TEXT references $mvv(58). IIRC the $mvv function is related to Caché MultiValue.
BTW, your reference to %Session.Language probably needs to be %session.Language instead.
Interesting to see that $$$TEXT references $mvv(58). IIRC the $mvv function is related to Caché MultiValue.
BTW, your reference to %Session.Language probably needs to be %session.Language instead.
Since the release of Serenji 2.6 back in July 2016 there have so far been two maintenance releases. Full history is here.
The 2.6.2 release earlier this week includes the classes that permit low-level Ensemble debugging on the most recent Ensemble release, 2017.1.
Arpitha, you can mark Sergei's answer as accepted by clicking the checkmark alongside it above. For a hint, see my clip below:

Chris, I'm interested to know why you're not mirroring your code as well. What do you do to make sure that if the secondary takes over from the primary it'll be running exactly the same code as was running on the primary? Or don't you want it to do that?
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 ![]()
I'm not able to answer your question, but I think you'll have a better chance of finding someone who can do if you edit your post and tag it with Ensemble and HealthShare. Also worth mentioning that the "Developer Community" tag is primarily intended for feedback about the DC software itself.
Here's the base implementation of this method in %Library.GlobalIdentifier (2017.1 version):
/// If a persistent class is GUIDENABLED then this method can be called to override the default GUID assignment. /// This method accepts a guid value and returns the override value currently assigned. The return value will only /// differ from the supplied value if the override is unsuccessful. It is only valid to call this method on a new object. /// The guid value passed to this method is not validated. It is up to the user to make sure the guid is properly formed. /// The guid assignment does not actually occur until the object is saved. If the object has already been assigned a GUID /// or if the GUID override value has already been assigned to another object then the GUID override value will be discarded. /// The check for GUID value uniqueness and a GUID value previously assigned is done only at the time the object is saved and is /// not performed by this method. Method %OverrideGuidAssignment(pGUID As %Library.CacheString) As %Library.CacheString { set i%"%%GUID" = pGUID quit i%"%%GUID" }
If I understand Alex correctly, he's calling this method in order to force a new instance of a GUIDENABLED class to have a specific GUID instead of getting one automatically assigned at save. He's not overriding the class in his own class definition.
I have highlighted in yellow some sentences in the comment that may be relevant.
I have also highlighted in pink the sentence Alex quoted, which is a bit unclear. By "return value" I think it means the GUID of the object instance after the save has subsequently been performed.
Steve, it may be worth you adding the "MultiValue Basic" tag to your question (which you can edit).
I haven't yet seen much MV traffic here on Developer Community. This lookup of posts with the "MultiValue Basic" tag currently only shows ones created by Community Manager. This Google Group has existed for several years, and I wonder if the folk there have yet heard about DC.
Where did you get this code from?
Agreed. I see it from other Groups views, but not from the homepage list of posts.
I'm seeing this happen with every "Last answer" and "Last comment" link that I've tested in the Developer Community Feedback group. I haven't seen the same problem with those links in posts in other groups.
Today's DC update means that questions with an accepted answer have the background of their answer count box shown differently. In the screenshot below, the first question has received 3 answers but the OP hasn't marked any of them as accepted. The second has now answers, and the third has two, one of which has been accepted by the OP:

That's good, but when I click into the third question I am no longer shown which of the answers the OP accepted:

Prior to the DC update I would have seen a green checkmark alongside the accepted one.
Is this change deliberate, or an unintended side-effect of you no longer showing the checkmarks when they're not clickable (which means they're hidden from everyone except the OP)?
This has been fixed by today's DC update.
Daniel, you posted this as a Question but perhaps it should be an Article. If so, I think you can change that.
In case you haven't already reviewed it, this article by @Murray Oldfield contains some debugging tips that could be useful.
Looks like something broke. I tried to use the "Last answer" link to see what you said:

But this is all it gave me:

Any information appearing in cconsole.log on the server? Or in the audit database?
Is this a local SNMP service connecting to a local Ensemble instance? Any chance of it being a firewalling issue?
The announcement post includes the following information:
It includes hundreds of bug fixes and new features, including:
* DeepSee improvements to the Folder Manager and Dashboard Filters
* iFind and iKnow improvements like coocurrence search, REST API extensions, and performance when building iKnow domains
* Improved XML VDoc performance in Ensemble
* Caché Nodejs now supports Node 7