%On... callbacks are served and integrated into he OBJECT world and typically don't care about any Trigger.

Triggers live in the SQL TABLE world of your class, with a hand full off %-variables unknown at the Object side
and without an actual instance of object but directly writing to Globals.

Take a look to the generated .INT code of your class and see what you have at hands.
I always found it quite ambitious to attempt a common code of both sides when directly changing Objects or Tables.

Summary:
- for SQL access have Triggers
- for Object access have your %On* methods

Applies only before 2014.1 as pointed out. 
But Trigger code doesn't look much better. 

something similar:

start ;
 open infile:"R":0 else  write "input file not found",! quit
 open outfile:"WNS":0 else  write "error creating output file",! quit 
 set $Zt="end"
 for line=1:1:5 {
  use infile read sql use 0
  if $e(sql,1,6)'="SELECT" continue
  set rs=##class(%ResultSet).%New()
  set sc=rs.Prepare(sql)
  set:sc sc=rs.Execute()
  if 'sc write "bad SQL statement",! quit
  set cols=rs.GetColumnCount()
  use outfile
;; fill in headers if required
  while rs.Next() {
   for cols=1:1:cols write rs.GetData(cols),$c(9)
   write !
  }
  write !,"###",!
  use 0
 }
 
end set $ZT=""
 close infile,outfile quit
 
!! NOT TESTED !!

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=...