create table t(id int, s varchar(36));
create sequence g; 
commit;
insert into t select gen_id(g,1), uuid_to_char(gen_uuid()) from rdb$types,rdb$types,rdb$types rows 10000000;
commit;
create index t_id on t(id);
commit;

 step 1. Коннект-1: 
SQL> out nul;
 -- предварит. вычитка в память страницы, её статистика нам не нужна:
SQL> select * from t where id between 7894561 and 7894570;
SQL> set stat on;
-- теперь читаем снова и обращаем внимание, что reads = 0 - это гут, всё прочиталось только из памяти:
SQL> select * from t where id between 7894561 and 7894570 for update with lock;
Buffers = 256
 Reads = 0 
Writes 0
Fetches = 254
-- коммит/роллбак не делаем, держим записи заблокированными.
-- Мы ведь при этом владеем блокировкой в ЛМ ?

 step 2. Коннект-2: 
SQL> commit; set transaction no wait;
SQL> update t set s='upd at '||cast('now' as timestamp) where id between 7894561 and 7894570;
-- всё правильно, обламываем его:
Statement failed, SQLSTATE = 40001
lock conflict on no wait transaction
-deadlock
-update conflicts with concurrent update
-concurrent transaction number is 34

 step 3. Коннект-1: 
-- блокировка записей, полученная на шаге-1, НЕ снята!
SQL> select * from t where id between 7894561 and 7894570;
Buffers = 256
 Reads = 1 
Writes 0
Fetches = 254

SQL> create table t2(id int, s varchar(50)); commit;
SQL> insert into t2 values(1, rpad('',30,'row #1'));
SQL> insert into t2 values(2, rpad('',30,'row #2'));
SQL> insert into t2 values(3, rpad('',30,'row #3'));
SQL> insert into t2 values(4, rpad('',30,'row #4'));
SQL> insert into t2 values(5, rpad('',30,'row #5'));
SQL> select rdb$db_key,id,s from t2;

DB_KEY                     ID S
================ ============ ================================
810000000 1 000000            1 row #1row #1row #1row #1row #1
810000000 2 000000            2 row #2row #2row #2row #2row #2
810000000 3 000000            3 row #3row #3row #3row #3row #3
810000000 4 000000            4 row #4row #4row #4row #4row #4
810000000 5 000000            5 row #5row #5row #5row #5row #5

commit;
set transaction no wait;
set term ^
execute block as
declare v_id type of column t.id;
declare v_f01 type of column t.f01;
begin
  for select f01,id from t into v_f01, v_id do
  begin
    begin
      update t set f01=f01 where id = v_id;
      when any do begin end
    end
  end
end^
set term ;^
rollback;

DB_KEY                     ID S
================ ============ ===================
8100000005000000            5 row #5row #5row #5row #5row #5
8100000004000000            4 row #4row #4row #4row #4row #4
8100000003000000            3 row #3row #3row #3row #3row #3
8100000002000000            2 row #2row #2row #2row #2row #2
8100000001000000            1 row #1row #1row #1row #1row #1

SQL> create sequence g; commit;
SQL> recreate table t(id int, s varchar(32760)); commit;
SQL> create index t_id on t(id); commit;
SQL> insert into t3 select gen_id(g,1), rpad('', 32760, uuid_to_char(gen_uuid())) from rdb$types,rdb$types rows 1000; commit;

 step 1. Коннект-1. 
SQL> out nul;
SQL> set stat off; select * from t where id=1; set stat on;
SQL> select * from t where id=1;
Reads = 0 -- OK, вся длинная запись была в кеше, на диск не лезли

 step 2. Коннект-2. 
-- апдейтим запись, которая находится стопудово не на той же странице, что с id=1:
SQL> update t set s=null where id=999;

 step 3. Коннект-1. 
SQL> select * from t where id=1;
Reads = 1 -- хоп! откудова это ? ведь коннект-2 на 99.(9)% не мог запрашивать эту же страницу!

 step 4. Коннект-2. 
SQL> rollback;

 step 5. Коннект-1. 
SQL> select * from t where id=1;
Reads = 1 -- опять!

SQL connect-2> update t set s=null where id=555;
   SQL connect-1> select * from t where id=1; -- ==> reads=1
SQL connect-2> update t set s=null where id=888;
   SQL connect-1> select * from t where id=1; -- ==> reads=1
SQL connect-2> update t set s=null where id=444;
   SQL connect-1> select * from t where id=1; -- ==> reads=1

SQL> recreate table t(id int, s varchar(32760)); commit;
SQL> create index t_id on t(id); commit;
SQL> insert into  t  select gen_id(g,1), rpad('', 32760, uuid_to_char(gen_uuid())) from rdb$types,rdb$types rows 1000; commit;
SQL> quit;

 Коннект-1. 
Database:  192.168.0.201/3252:empty25
-- вычитываем в кеш:
SQL> out nul; select cast(right(s,10) as varchar(10)) rs,current_timestamp dts from t where id=1; out; set stat on;
-- проверяем, что на диск больше лезть не надо:
SQL> select cast(right(s,10) as varchar(10)) rs,current_timestamp dts from t where  id = 1 ;

RS                               DTS
========== =========================
C7402EA022 2013-12-13 23:53:54.5810

Current memory = 1543088
Delta memory = 0
Max memory = 1581632
Elapsed time= 0.02 sec
Buffers = 256
 Reads = 0  -- ОК, так и есть
Writes 0
Fetches = 19

 Коннект-2. 
C:\MIX\firebird\fb25>isql 192.168.0.201/3252:empty25 -n -c 256
Database:  192.168.0.201/3252:empty25
SQL> update t set s=null where id  = 4 ;

 Коннект-1. 
SQL> select cast(right(s,10) as varchar(10)) rs,current_timestamp dts from t where id = 1;

RS                               DTS
========== =========================
C7402EA022 2013-12-13 23:54:10.8780

Current memory = 1543088
Delta memory = 0
Max memory = 1581632
Elapsed time= 0.01 sec
Buffers = 256
 Reads = 1
Writes 0 
Fetches = 19

 Коннект-2. 
SQL> rollback;

 Коннект-1. 
SQL> select cast(right(s,10) as varchar(10)) rs,current_timestamp dts from t where id=1;

RS                               DTS
========== =========================
C7402EA022 2013-12-13 23:54:20.6590

Current memory = 1543088
Delta memory = 0
Max memory = 1581632
Elapsed time= 0.01 sec
Buffers = 256
 Reads = 1
Writes 0 
Fetches = 19

gstat EMPTY25.FDB -r -t T|findstr /i /c:"data pages"

    Data pages:  192 , data page slots:  192 , average fill: 88%