How about also updating the beta repo to 1.2.119 ? As things stand I had to add the 1.2 Stable repo to my list of sites in order to update my 1.2.118 beta to 1.2.119
- Log in to post comments
How about also updating the beta repo to 1.2.119 ? As things stand I had to add the 1.2 Stable repo to my list of sites in order to update my 1.2.118 beta to 1.2.119
I doubt if Studio will be able to compile them faster than Terminal can. After all, when Studio compiles them, it asks the server to do the work. That's also where your Terminal compile happens.
It sounds like you're seeing the same value in the "License Id" column as in the "ID" column. So I guess your Cache was installed with Minimal security and you're not requiring Portal users to supply credentials, right?
It's my experience that when CSP users (e.g. Portal users) have to authenticate, the "License Id" field of their CSP Session record includes the IP address they're connecting from, as well as the username they logged in with. This can be useful in working out who is using all the sessions.
When you view the CSP Sessions page in Portal, does the "License Id" column give you any useful information?
Yes, the badges seem to get awarded retrospectively. But for some reason the Challenges section of my Global Masters page still lists the associated challenges for two badges I've already received:

Manish, IMO you really need to open a support ticket with InterSystems about this kind of issue. DC isn't a substitute for the excellent support that InterSystems WRC can offer.
Yes, please do that Nicole.
Nicole, this inconsistency between Atelier Explorer (where some packages are shown as white) and Server Explorer (where none are) still exists in 1.2. For example, in AE the %Compiler package is white because it contains no classes, only subpackages:

In SE this doesn't happen:

Is it still on someone's radar there?
Nicole, after starting once with the -clearPersistedState command-line switch I am now able to use my original workspace.
Intriguingly, after doing this both my original workspace and the fresh one I had created after upgrading to 1.2 now complain about connecting to a server whose /api/atelier web app only accepts Unauthenticated access. Before "-clearPersistedState" my freshly-created workspace was willing to connect to such a server (incidentally, that server was a fresh install of IRIS 2018.1.1, which still offers Minimal Security as an install option).
This seems to have been addressed in Atelier 1.2. Using build 118 from the beta repo I get the following when testing a connection to a server installed with Minimal security (which somewhat surprisingly is still an option when installing IRIS 2018.1.1)

To resolve this I must enable another authentication method (e.g. Password) on the /api/atelier web app:

Probably a good idea to deselect Unauthenticated. Even though Atelier doesn't seem to allow anonymous connection to /api/atelier REST service I guess it'd be possible to do this directly.
I switched to my upgraded 1.1 workspace and tried a couple of times launching Eclipse with 'eclipse -clean' but still get the errors. It's not critical for me, as it was only a play workspace. But it might matter more to other folk if they have the same experience.
Update: starting with a fresh Eclipse workspace seems to be helping...
For the record, it seems 1.2 has appeared in the Beta repo that's documented at https://download.intersystems.com/download/atelier.csp#plugin -
https://atelier.artifactoryonline.com/atelier/updates/beta/latest/
Hmm, not looking too good so far:

Sounds like a case for WRC.
Where are you running the GBLOCKCOPY? If on your 2014 environment I think you'll be having the same problem as when you just tried to mount the database there. GBLOCKCOPY needs to mount it before it can copy block from it to your new database.
Most likely, your original database has 2KB blocks. Your problem then is, 2014 can't mount any databases with 2KB blocks. The last version supporting 2KB block databases was 2011.1. See here.
What Cache version are you using?
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.