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

Alongside the CACHE.DAT file is there a cache.lck file? If so, this could be preventing the new Cache instance from mounting the CACHE.DAT file by indicating that the database is currently mounted by another instance.

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.

When you view the CSP Sessions page in Portal, does the "License Id" column give you any useful information?

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"
 }

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.

What Cache version are you using?

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.