The rules about indirection in ObjectScript can be a bit tricky to comprehend. Your last line is syntactically invalid.

Use this instead:

S @("C="_B)

I haven't tested this myself, but did you try using the OnInit() callback method?

There's a bit of information here.

Maybe you're already doing this and finding $username="_Ensemble"

Could you use the SQL Gateway feature to make your tables accessible there?

Your SetPersistentValue calls refer to LastModified, but your query refers to LastUpdated. Is this a typo in your post?

If you use Portal (Explorer, SQL) to run a query that reports LastUpdated values, what do they look like? More technically, what datatype are they?

Since you're using Ensemble, you may also like to know that Deltanji integrates with the Portal-based editors and with Studio, as well as with Atelier. It is server-side source control, so has no problem with scenarios where multiple developers work as a team in a single namespace.

Manish, I highly recommend you use the normal support channel for this, i.e. contact WRC.

It worked for me (2017.2.2 on Windows):

C:\InterSystems\Ens172\bin>CSESSION ENS172 < c:\s\try.script

Node: TIN, Instance: ENS172

USER>zr

USER> ; Test routine created by try.script file

USER> w !,"This is written by INT routine ",$t(+0)

USER> w !," which is created from a script injected to csession."

USER>zs MyBootRoutine

USER>d ^MyBootRoutine

This is written by INT routine MyBootRoutine
 which is created from a script injected to csession.
USER>; Clean up

USER>zr  zs MyBootRoutine

USER>h

C:\InterSystems\Ens172\bin>

Maybe your indented script lines (the ones to insert into the routine) aren't starting with $C(9)

Make your script create an INT routine and run it. Example try.script below. Your lines of code either begin with the TAB character or with a label followed by TAB.

zr
    ; Test routine created by try.script file
    w !,"This is written by INT routine ",$t(+0)
    w !," which is created from a script injected to csession."
zs MyBootRoutine
d ^MyBootRoutine
; Clean up
zr  zs MyBootRoutine
h

Anyone watching this thread may find the following answer from @Alexander Koblov on another thread helpful.

https://community.intersystems.com/post/atelier-connection-broken-error##node-450031

Anyone watching this thread may find the following answer from @Alexander Koblov on another thread helpful.

https://community.intersystems.com/post/atelier-connection-broken-error##node-450031

If you are indeed telling Studio to use the same Web Server Port that you're successfully using with Atelier, then that's your problem. Studio connections are handled by the Superserver port (e.g. 1972), not the Web Server one (e.g. 57772).

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.

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.

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.

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.

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.

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.