go to post John Murray · Jun 12, 2018 If you use the IF style, I suggest you also consider using the ELSEIF clause. See doc here. set caseSwitch = 1 if (caseSwitch = 1) { write "Case 1" } elseif (caseSwitch = 2) { write "Case 2" } else { write "Default case" }
go to post John Murray · Jun 12, 2018 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:
go to post John Murray · May 31, 2018 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.
go to post John Murray · May 29, 2018 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?
go to post John Murray · May 29, 2018 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).
go to post John Murray · May 29, 2018 Thanks for posting the 1.2 info Joyce.Beta testers upgrading from a previous version may find useful additional info in my earlier post here.
go to post John Murray · May 29, 2018 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.
go to post John Murray · May 25, 2018 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.
go to post John Murray · May 25, 2018 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/
go to post John Murray · May 23, 2018 I'm not sure that GBLOCKCOPY is able to cope with you specifying the same filepath for the source and destination databases.GBLOCKCOPY doc for 2008.1 is here.
go to post John Murray · May 22, 2018 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.
go to post John Murray · May 16, 2018 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.
go to post John Murray · May 16, 2018 Might be wise to amend your code so you check the status code returned by each of the methods you're calling.
go to post John Murray · May 15, 2018 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:TSTARTDo ##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.
go to post John Murray · May 14, 2018 @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?
go to post John Murray · May 14, 2018 I also recommend that you look at this YouTube playlist of useful videos about Atelier.
