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.

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.

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.

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:

https://community.intersystems.com/post/automatic-crossposting-developer-community-google-group-user-intersystemsdc

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

http://docs.intersystems.com/cache20171/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25SYS.Task

I'm seeing ExportTasks and ImportTasks methods, both inherited from %SYS.TaskSuper