Sorry, I don't have any Doc reference at hands.
Eventually someone of the Atelier team has.

Out of practical observation
there is a quite fundamental shift in the editing paradigm between Studio and Atelier.

Studio does Server based editing. What you change is there and during your changing session
you lock the Class, Routine, ... So you act as single owner at that time and
anyone else trying to change something gets an immediate alert.  
It's the "Highlander Principle" (according to the film"There can be only One" http://wiki.c2.com/?HighlanderPrinciple
It's based on classical LOCK logic. "Pessimistic Locking"

Atelier acts on your local copy and no one else might know unless you use some source control. !!

At compile time your copy is checked and if it was changed you get a nice Text-Diff to decide how to to proceed.
So we see "Optimistic Locking" or "Versioning".

You can easily reproduce this:
    - open some Class or Routine in Studio and do any change (e.g. Comment) but no compile or save
    - open the same with Atelier. - no alert
    - change it in Atelier. - no alert
    - save it in Atelier. NOW you get your alert from server but you keep your local copy.
    - save your copy in Studio. - you are the winner

next:
    - do some dummy change in Atelier (I found no other way)
    - save it in Atelier and you get the Text-Diff with your version and the actual server version
     but as in past you get no hint how many changes you may have missed.

personal remark:
I think at that point latest anyone should have understood the importance of source control.
to know of an intended change in advance and his history later.
 

having this done ~ 9 yrs back I can't resist to share my old solution (at that time for a UNIQUE on 2000  char)

- split Text into 4 sections in calculated properties e.g.
tx1 = $e(Text,1,500)
tx2 = $e(Text,501,1000) 
tx3 = $e(Text,1001,1500)
tx4 = $e(Text,1501,2000)

- index them
- then you can build an SQL  statement to have all 4 pieces identic.
you end up with a cascade of embedded SELECTS

It's not to fast but very precise.
 

Found it:

Exceptions to READ COMMITTED  1 of some more

If you query contains an aggregate function, the aggregate result returns the current state of the data,
regardless of the specified ISOLATION LEVEL. Therefore, inserts and updates are in progress (and may subsequently be rolled back) are included in aggregate results. Deletes that are in progress (and may subsequently be rolled back) are not included in aggregate results. This is because an aggregate operation requires access to data from many rows of a table.

see:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

Hi Eduard !

Being a little bit lazy I simplified the query (for less typing)
My example: 

SELECT * FROM %Dictionary.StorageDataValueDefinition
where id [ 'Sample.Person'

And it works fine for persistent and serial classes.
My hidden assumption: there is only 1 Storage Strategy.

The nice point about:
you get also storage locations of deleted (!!) properties  
that eventually might be invisible in class definition.
 
yes yes

Assumimg you have both DB on the same instance but different namespaces "FROM" and "TO"

You may run a loop like this

set id=""
for cnt=1:1 {
  set id=$ORDER(^|"FROM"|Data(""),1,value) quit:id=""
  set ^|"TO"|Data(id+10000000)=value)
  if cnt#100000 write cnt,?10,id,!
}

For the connections of the host you may use ECP

For a more structured global you might need to use $QUERY()

The write is just to see progress

You may define properties by writing to ##class(%Dictionary.PropertyDefinition)
as part of a ##class(%Dictionary.ClassDefinition) 
http://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?P...

Parameters is then defined as array of %CacheString;  

And you set it just as any other array.  [SetAt() ..... ]

and then compile the class to use that property inside the class
 
This is nothing you may do on the fly.
 

YES it is !

Class %DeepSee.ResultSet has a method %CancelQuery that does the trick.

http://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?P...

http://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?P...

Chapter  Using the Result Set API tells you some more details.
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

especially:

If you used %ExecuteAsynch(), periodically check to see whether the query has completed. If the query uses any plug-ins, make sure that any pending results are also complete; pending results are the results from the plug-ins, which are executed separately from the query.

To determine the status of the query, call the %GetStatus() method of your instance. Or call the %GetQueryStatus() class method of %DeepSee.ResultSet. These methods return the status of the query and also (separately) the status of any pending results; see the class documentation for details.

Optionally, to cancel a query that has not yet completed, call the %CancelQuery() class method.

A practical example is seen in ##class( %DeepSee.UI.Analyzer). onunloadHandler()