vadiminfo hvlad
Требование cursor stability появилось значительно позже, чем IB.

А какому уровню изоляции в стандартах SQL соответсвует это требование? Я нашел, что оно используется (в смысле термин cursor stability) в DB2. Уж не READ UNCOMMITED? И что означает, что это требование не выполняется в IB? Там что может быть? Уже не разрешение грязного чтения к транзакциям типа READ WRITE? Или что?Я не нашел в SQL2002 упоминания этого термина.
Он не связан с уровнем изоляции, AFAIU. В IB\FB нет возможности прочитать незакоммиченные другой тр-цией данные, т.е. уровень изоляции READ UNCOMMITED (dirty reads) не поддерживается.

Можно получить ссылку на то место в документации к DB2, где определяется cursor stability ?

f_w_pА как же "ORA-01555"? Что это за "версионник", к-рый не поддерживает целостность чтенния. Про какую там ACID можно говорить?:-)1. я не знаю, что такое "ORA-01555" применительно к IB\FB
2. Вместе с Yo!! покажите - где нарушается ACID в FB

ЛПinsert into a (f1,f2,...,fn) select f1,f2,...,fn from a WHERE f1=xxxx And id<1000000000

?Если id - это PK, заполняемый в триггере, то этот запрос отработает так, от него ожидается, т.е. бесконечной вставки не будет.
Смысл ограничения по f1 не понятен

vadiminfo hvlad
Можно получить ссылку на то место в документации к DB2, где определяется cursor stability ?

Я откопал этот термин в Книге Дейта "Введение в БД". Там он упоминался в контексте рассуждений про уровни изоляции на примере DB2, насколько я понял. Там типа их два. Этот первый. Правда, там как-то не совсем ясно. Было поздно - не мог внимательно про всю идею. Зачем он нужен када есть другие.
Или это есть комбинация этих других или чать от того, часть от другого. Пока не въехал.
Но что значит, что это не выполняется в IB? Чем это горозит? Мож там что другое , получше выполняется вместо этого? Я вот не могу найти точного определения cursor stability - только интуитивные.
Не выполняется в IB\FB - оператор видит внесённые им самим изменения. Т.е. insert into t select * from t зацикливается.

Чем грозит ? Кол-во известных граблей перечислимо пальцами однй руки. В основном это грозит подобными флеймами :)

К изоляции тр-ций это не имеет никакого отношения, просто подробности реализации. FB не формирует всё множество вставляемых строк перед собственно вставкой, как того стал требовать стандарт с некоторых пор. Он работает проще : нашёл строку - вставил её.


vadiminfo hvlad
В IB\FB нет возможности прочитать незакоммиченные другой тр-цией данные, т.е. уровень изоляции READ UNCOMMITED (dirty reads) не поддерживается.

Т.е. наоборот, поддерживается? Раз нельзя прочитать незакоммиченные.Ещё раз, медленно - READ UNCOMMITED (грязное чтение) подразумевает возможность прочитать данные, незакоммиченные другой тр-цией. Этот режим в IB\FB не существует, т.е. READ UNCOMMITED не поддерживается.

vadiminfoВпрочем, как толковать термин подерживается. Грязное чтение не возможно там за счет чего?За счёт того, что это версионник. Он знает
а) какая тр-ция породила данную версию записи
б) в каком состоянии эта тр-ция
Если тр-ция, породившая самую свежую версию записи, ещё активна, то IB\FB будет либо читать предыдущие версии, либо ждать окончания этой тр-ции, либо сразу скажет о конфликте. Конкретное поведение зависит от уровня изоляции и режима ожидания читающей тр-ции