Yo.!делаем IOT таблицу (что бы гарантировать, что пишем в начало и конец)
create table shit (id int primary key, a varchar2(20)) organization index;в ФБ, к сож-ю, нет такого вида таблиц, на сегодня - только heap.
Но для проверки того, где сидит запись, в "начале" или в "конце" таблицы, можно юзать системное поле с именем rdb$db_key. Чем оно меньше, тем ближе запись к "началу" таблицы. Что я далее и сделаю.
Yo.!сколько записей проапдейтит FB ? практически наверняка, проапдейтит 1000001, а 1 оставит нетронутой.А вот и проверим. Создаём новую базу, наталкиваем в неё 999999 строк:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
session #1
C:\MIX\firebird\fb25>isql T0.FDB
Database: T0.FDB
SQL> create table t(id int, f01 int); commit;
SQL> set term ^;
SQL> execute block as
CON> declare i int=2;
CON> begin
CON> while (i<=1000000) do insert into t values(:i, :i/2) returning :i+1 into i;
CON> end^
SQL> set term ;^
SQL> commit;
SQL> select first 5 rdb$db_key,id,f01 from t;
DB_KEY ID F01
================ ============ ============
8000000001000000 2 1
8000000002000000 3 1
8000000003000000 4 2
8000000004000000 5 2
8000000005000000 6 3
SQL> select first 5 rdb$db_key,id,f01 from t where id>=999995;
DB_KEY ID F01
================ ============ ============
800000009DA03000 999995 499997
800000009EA03000 999996 499998
800000009FA03000 999997 499998
80000000A0A03000 999998 499999
80000000A1A03000 999999 499999
-- как видно, младшим значениям поля ID соотв-вуют меньшие значения RDB$DB_KEY, т.е. записи легли в натуральном порядке.
-- Теперь удаляем первые 10 строк, делаем commit:
SQL> delete from t where id<=10; commit;
Далее запускаем второе isql-окно, и вводим там команду вставки + коммит, но
БЕЗ нажатия Enter'a:
1.
2.
3.
session #2
C:\MIX\firebird\fb25>isql T0.FDB
Database: T0.FDB
SQL> insert into t values(-1, 1000 ); commit; -- Enter пока НЕ нажимаем!
Идём снова в первое окно:
1.
2.
session #1
SQL> set transaction read committed record_version no wait;
SQL> update t set f01= null where id>-999999; -- и жамкаем ENTER
Переключаемся во второе окно и жамкаем там тоже Enter:
1.
2.
session #2
[Enter]
SQL> _ -- выполнилось ОК.
Ждём окончания выполнения в первом окне, затем вводим там:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
session #1
SQL> select rdb$db_key,id,f01 from t where id>=999995;
DB_KEY ID F01
================ ============ ============
800000009DA03000 999995 <null>
800000009EA03000 999996 <null>
800000009FA03000 999997 <null>
80000000A0A03000 999998 <null>
80000000A1A03000 999999 <null>
80000000A2A03000 1000000 <null>
SQL> select rdb$db_key,id,f01 from t where id=-1;
DB_KEY ID F01
================ ============ ============
80000000 A7E83000 -1 <null>
Таким обр., session #1 увидела запись, добавленную в session #2 с id=-1. Я так понимаю, что произошло это из-за добавления этой записи не в дырку, образованную от удаления первых 10 строк, а именно в конец таблицы (см её RDB$DB_KEY).
Я не знаю, всегда ли так происходит - это лучше у ФБ-разрабов спросить. Если строка будет добавлена действительно в начало таблицы, то апдейт уже не увидит её, конечно.
