Maybe your code at someLabel^someRoutine in OTHERNAMESPACE calls another routine that exists only in OTHERNAMESPACE. In that case, the <NOROUTINE> error will occur when the call is made. That's because when you d someLabel^|”OTHERNAMESPACE”|someRoutine(inputVar,.resultByReference) you are fetching the routine someRoutine from the database of the OTHERNAMESPACE namespace, but you are executing that code in your current namespace.

This is not the same as swapping to OTHERNAMESPACE, running the code, and then swapping back. For example, if someRoutine accesses globals it will do that from whichever namespace is current.

To see an example of this, try the following:

SAMPLES>w $zv
Cache for Windows (x86-64) 2016.2 (Build 636U) Wed Apr 13 2016 20:58:35 EDT
SAMPLES>d main^lookup
 
Lookup: 1-jan-2016...finding birthday...no matches
Lookup:
SAMPLES>zn "user"
 
USER>d main^|"SAMPLES"|lookup
 
Lookup: 1-jan-2016
<NOROUTINE>main+27^lookup *datent
USER 4d1>
 
USER 4d1>q
 
USER>

The code in main^lookup in the SAMPLES namespace calls $$validDOB^datent. When this is attempted from the USER namespace we get a <NOROUTINE> error. Notice that the extended information in the error tells us that the routine it can't find is datent.

The port info is also available from the "About" link at the top of Portal:

Thanks to James for a prompt and detailed reply to my breakfast table question. Here I'm going to add this link to a previous posting of mine about %ALL, in part to highlight that %ALL mappings don't apply to 100% of the namespaces you have. The DOCBOOK and SAMPLES namespaces are apparently exempt. I can rationalize the DOCBOOK extension to myself, but the SAMPLES one puzzles me, especially given that the ENSDEMO namespace of an Ensemble or HealthShare instance is not exempt even though it's effectively another "samples" namespace.

Here's what the Properties tab shows when I select my Samples project in Project Explorer:

Is yours not doing this? If not, what Atelier version do you have? Mine is 1.0.128

Adding to this, I'm not 100% clear on the relationship between Communities/Groups and Tags. Some tags seem to correspond to communities/groups, other tags don't. When I look at an arbitrary post and want to know what Community/Group it belongs to, how do I tell? Look for a tag that is also a community? What if more than one tag qualifies?

If your READ from wrappercomp raises an error (e.g. end of file) you don't have anything in place to catch this error, CLOSE wrappercomp and USE olddev once more. I suggest you add some code (for example a TRY/CATCH block) to do this, and also to tell you what the error was. That information might help you find out why the wrappercomp pipe didn't work as you expected.

I think a "GRANT EXECUTE ON SCHEMA xyz TO roleA, roleB" should be sufficient to give users with roleA or roleB the ability to run any stored procedure defined by any class in your xyz package, even classes / procedures that you haven't yet written.

AFAIK only the owner of the class (set using the Owner keyword on the class, defaulting to _SYSTEM) has automatic rights to invoke all of the SQL stored procedures that the class implements (as classmethods with the SqlProc keyword). Anyone else who needs to be able to invoke them will need the right granting to them, either directly or via a role.

Tiago,

Do you mean that when you are writing output from the server (e.g. from a source control class) you want to be able to control the colour of that text? I have never discovered a way of doing that, but let's see if anyone at ISC knows of an undocumented feature there.

This is a good question. One of the potential benefits of moving to Eclipse is the increased potential for an ecosystem compared to the Studio days. I think that even if Atelier source isn't opened up to us we will still be able to add stuff around it. But it would certainly be cool if InterSystems released it as open source.

No, I don't think you have to switch over to the new paradigm until you're completely ready to (e.g. no-one using Studio anymore). Instead, follow Dmitry's steps, creating an Atelier project containing any of the classes that you want to edit. Don't hook the Atelier project up to an Eclipse source control provider; your namespace and the existing server-side source control class should continue to function the way it always has done.

This is how we anticipate existing users of our Deltanji (formerly VC/m) source control product will deal with the introduction of Atelier.  And perhaps not just existing users, seeing as Deltanji is available as a free Solo edition.

Indeed. Presumably the "load and delete" defaults were a design decision based on the model of running unit tests elsewhere. That seems relevant for a build server, but not so friendly for the developer who you're trying to persuade to code the tests in the first place. Yes, Studio the source control hook facility can be your friend here provided you're prepared to spend enough time getting intimate with it.

Re your Atelier issue, does the "Configure server" link lead you to somewhere you can test the connection? Make sure that your Atelier connection is pointing to the port that your Cache Portal also goes to, and not to the port that your Cache Studio uses. That was an early gotcha for me in Atelier.

The Cache username that you connect with might not have enough privileges. One way to determine if this is you problem is to grant the user the %All role temporarily.