Do you have login credentials for WRC Online at http://wrc.intersystems.com/ ?
Once you have logged in, use the "Online Distributions" link. You'll need to contact your InterSystems account manager to request a license key.
Alternatively, get your hands on InterSystems IRIS in the cloud here.
Might be wise to amend your code so you check the status code returned by each of the methods you're calling.
The TROLLBACK command doesn't automatically release LOCKs that were acquired within the transaction. The TROLLBACK documentation is a bit confusing in this regard. At one point it says this:
Then later on the same page this text seems to say that both TROLLBACK and TCOMMIT do release locks.
Jordi, in your example:
TSTART
Do ##class(MyTable).%OpenId(<TableID>, 4) (This internally is creating a Lock +^User.MyTable(<TableID>)
TROLLBACK (This action removes the previous lock)
I don't think it's the TROLLBACK that's releasing the lock, but rather the destruction of the oref that the %OpenId method created. Indeed, if tested exactly as you wrote it that oref doesn't even get stored in a local variable, so ceases to exist as soon as the method call completes.
@Ponnumani Gurusamy - when your Atelier problem is solved and you are able to save and run the sample routine you showed us in your screenshot, what do you predict the output will be?
I also recommend that you look at this YouTube playlist of useful videos about Atelier.
First you need to create an Atelier Project, which is a type of Eclipse project suitable for containing MACs, classes and other InterSystems code entities.
From the File menu, select New, then Atelier Project.
The RemoteSystemsTempFiles project isn't an Atelier Project. You can learn more about RemoteSystemsTempFiles here.
The old Google group isn't owned or managed by InterSystems, and previous attempts to get whoever does manage it to do anything to tackle the potential confusion etc have been unsuccessful. There are several other posts here on DC about this. For example:
For others, search DC for the term "Google".
That's the doc for the %SYS.Task package. One row above it in the Documatic explorer panel you'll find the link to the %SYS.Task class. Here's a link to the online copy for 2017.1
I'm seeing ExportTasks and ImportTasks methods, both inherited from %SYS.TaskSuper
Did you find the ExportTasks and ImportTasks classmethods of %SYS.TaskSuper, which AFAIK is the superclass of all tasks?
I haven't tried them myself, but at first sight they look promising.
I disagree with your assertion that you can't call at a tag in a way that you can call from the top:
USER>zp
YJM w !,"Runs in ",$namespace,! q
;
SUB ; A subroutine tag
w !,"SUB^YJM runs in ",$namespace,!
q
USER>zn "samples"
SAMPLES>d SUB^|"USER"|YJM
SUB^YJM runs in SAMPLES
SAMPLES>
I find it confusing that you talk about calling a routine in a namespace. As I see it you're fetching it from another namespace (i.e. the one the routine lives it), but you're running it in your current namespace.
You also need to be aware of what happens if the code you fetch from the other namespace makes its own calls to other code. Here's an illustration:
USER>zp
YJM w !,"Runs in ",$namespace,! q
;
SUB ; A subroutine tag
w !,"SUB^YJM runs in ",$namespace,!
q
;
Test1 ;
w !,"About to call local line label YJM",!
d YJM
q
;
Test2 ;
w !,"About to call a line label in a specific routine",!
d SUB^YJM
q
USER>d Test1^YJM
About to call local line label YJM
Runs in USER
USER>d Test2^YJM
About to call a line label in a specific routine
SUB^YJM runs in USER
USER>zn "SAMPLES"
SAMPLES>d Test1^|"USER"|YJM
About to call local line label YJM
Runs in SAMPLES
SAMPLES>d Test2^|"USER"|YJM
About to call a line label in a specific routine
d SUB^YJM
^
<NOROUTINE>Test2+2^YJM *YJM
SAMPLES 2d0>
SAMPLES 2d0>q
SAMPLES>
I didn't expect D ["SAMPLES"]YJM^YJM to work, but that's the syntax you used in your earlier comment. Probably a typo.
I agree, it's interesting that the older-style square-bracket extended reference syntax doesn't work in this context. You have to use the newer-style vertical-bar syntax.
Kenneth, I don't think you are correct here. Apart from invalid syntax you gave, even with the correct syntax the routine is fetched from the specified namespace and executed in the current namespace. See the following example using a simple test routine (YJM) that I created in my USER namespace and then executed from my SAMPLES namespace:
USER>zl YJM zp
YJM w !,"Runs in ",$namespace,! q
USER>d ^YJM
Runs in USER
USER>zn "SAMPLES"
SAMPLES>d ^YJM
D ^YJM
^
<NOROUTINE>^YJM *YJM
SAMPLES>d ^|"USER"|YJM
Runs in SAMPLES
SAMPLES>w $zv
Cache for Windows (x86-64) 2017.2.1 (Build 801U) Wed Dec 6 2017 09:07:51 EST
SAMPLES>d ["USER"]YJM^YJM
D ["USER"]YJM^YJM
^
<SYNTAX>^YJM
SAMPLES>
Like you, I get this error and find that simply stopping and restarting Eclipse resolves it.
I'm using Eclipse Oxygen (fully up-to-date) on 64-bit Windows 10, with the most recent publicly available version of Atelier 1.1 (IIRC, build 391).
My hunch is that your server namespace is set to use a source control class, and maybe that class is issuing a WRITE command at a point where the current device is the TCP socket that should be receiving a JSON response for forwarding to Atelier.
I don't know why this isn't working. Perhaps because you are running Studio in English but on a Windows instance with a different default locale?
But that is only a wild guess.
I wonder if any other DC readers have noticed templates not getting added to the MRU list.
Anyway, I suggest you ask InterSystems WRC for help.
Bob, your question doesn't belong in the "Developer Community Feedback" group, since that's for -- well -- feedback about Developer Community. Nor is the "Developer Community" tag appropriate for it, since that also is intended for posts about DC. Please edit your post, moving it to another group, perhaps "Ensemble", and removing the "Developer Community" tag.
UPDATE - it looks like someone (one of my fellow mods?) has moved it to the Ensemble group already. You can still remove the tag, and maybe remember not to post to "Developer Community Feedback" in future unless that's the nature of your post. Thanks!
My, how the years pass by. Latest update via WRC is this isn't going to get fixed in 2018.2, and no idea when/if it ever will be.
Sounds like you already have server-side source control (CCR) similar to the Deltanji product from my employer George James Software. In that case, your simplest option is to get your Atelier users to connect to the server instances in the same way as they currently do with Studio. There's no need to change your code management paradigm (and thus your source control system) as well as your editor.
I recommend you go through that Global Summit session Ben Spead referenced in his earlier comment.
What do you currently do with Studio? For example, does each developer install Studio on their local machine, then connect to whichever Cache /Ensemble server instance contains the namespace(s) they need to edit code in?
So, the "Templates..." option brings up a dialog that shows all the templates available to you? And that you can run one of them from that dialog? But after running that template, when you go back to the menu it doesn't show that template in the menu's MRU list?
To answer your request for info about the registry entries, here's what one of mine looks like:
That's odd. I just checked one of my Studios (2017.2.1) and it lists the templates I have used recently.
What does Help\About show your Studio version as?
I assume you have a document open in Studio when you look at that menu, because when no document is open it looks like this (both options disabled):
I think Studio manages this submenu's contents automatically as a most-recently-used list, and you can't directly control what gets listed.
But if I have misunderstood your question, and you're actually asking how to create your own template, then here is the doc link.
If you're not already committed(
) to using Git, you might consider the Deltanji source code management tool from my employer, George James Software. One of its features is the ability to manage deletion of code components (e.g. classes, routines, files, lookup tables, HL7 schemas etc) and propagate those deletion downstream in whatever workflow you have configured (e.g. DEV, QA, STAGING, LIVE).
The documentation is misleading about this. It says:
When you upgrade Caché to a new version, existing Query Plans are automatically frozen.
And later:
The earliest upgrade that performs this operation is an upgrade to 2017.1.0.
What it needs to say is:
The earliest upgrade that performs this operation is an upgrade from 2016.2.0.
The docs do use 2016.2 as the "from" version in their example, but not in a way that communicates how this nice feature won't help with upgrades from pre-2016.2 versions.
@Brendan Bannon - please draw this to the attention the InterSystems documentation team.
Above I've deliberately linked explicitly to the 2017.2 doc rather than to "latest" because I hope that in due course the latter will get corrected.
A bit more info on the answer from @Jeffrey Drumm
Here's how the relevant part of the 'Environment, Documentation and Proxy' section of Studio's Tools\Options dialog starts out:
In this state I can use the standard 'SOAP Wizard' add-in but it is served by the private web server of my Cache server installation. I'm testing from the Windows desktop this runs on.
I also have an instance of IIS on that Windows host, and the IIS is correctly configured to serve Portal and documentation pages from both http://localhost/ and https://localhost, plus from http://localhost/cache111 and https://localhost/cache111
Back in the Studio Options dialog I set the checkbox and start trying some value-pairs in the now-active Address and Port fields. Here are my results:
| Address | Port | Result of launching add-in |
|---|---|---|
| localhost | 80 | Success |
| localhost | 443 | White page, presumably because HTTP is requested from 443 |
| localhost/cache111 | 80 | CSP Error page, which reveals that the CGI variable CACHE_URL has the malformed value http://localhost:80/cache111:80/isc/studio/templates/SOAPClientWizard.csp |
| https://localhost | 443 | Works from Studio 2017.2.1 but fails from Studio 2014.1.1 and displays a page headed "Navigation to the webpage was canceled". |
| https://localhost/cache111 | 443 | Fails from Studio 2014.1.1 as above. Gives CSP Error page from Studio 2017.2.1, which reveals that the CGI variable CACHE_URL has the malformed value http://localhost:443/cache111:443/isc/studio/templates/SOAPClientWizard.csp |
Note too that if we enter a value for Address but leave Port blank the dialog files a value of 80 in the Port field. This can be seen when the dialog is reopened.
Conclusions from above:
Nice! And you can shave off 3 characters by using $EXTRACT instead of $SELECT
f i=1:1:s w ! f j=1:1:s w $e(" #",j#s<2!(i#s<2)!(j=i)!(s-i+1=j)+1)
No, a variable name cannot contain the underscore character, because that character is the concatenation operator. If it was allowed in a variable name, how would we interpret this, for example?
WRITE TICK_TOCK
Is it concatenating variables TICK and TOCK, then writing out the result? Or writing the value of a single variable named TICK_TOCK.
If the utility you refer to is expecting you to supply data values in variables whose names match the SQL column names, then the developer of the utility hasn't accounted for the fact that SQL column names can contain underscores but Caché variables can't. So the utility needs fixing.
For Windows the link http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCI_windows#GCI_windows_upgrade gets you to a short section titled "Caché Upgrade Installation".
For other platforms the principle is the same. Stop the Caché instance you're going to upgrade (or at least be prepared to allow the upgrade procedure to stop it). Then run the installer script in the same way as if doing a new installation. Pick the existing instance you want to upgrade.
Bob, as one of the moderators I have removed the "Developer Community" tag from your post. That tag is intended for posts or questions related to the operation of Developer Community itself.