vadiminfoВот выписываю Вам из Дейта. Из раздела 16.8 "Уровни изоляции".

"В качестве иллюстрации рассмотрим .... в СУБД DB2, стабильность курсора ...

При использовании ... уровня (Cursor Stability - CS) соблюдаются следующие условия:Спасибо за выписку.
Похоже DB2, как обычно, вводит собственные нестандартные уровни изоляции. Это их право, но, так как данный уровень определяется через блокировки кортежей, то его (определение) просто физически невозможно перенести на версионик FB, в котором отсутствует понятие блокировки записи.
Т.е. выводов относительно FB из этого определения сделать не возможно, к сожалению

vadiminfoА вот на счет чего отнести
insert into t select * from t зацикливается

интересно.

Наверное, на неправильную работу инструкцию insert. Ну что ж, багов везде хватает.Да, багов везде хватает, но не таких же ;) INSERT работает абсолютно нормально.
"Не нормально" работает комбинация INSERT + SELECT :
1. пусть в исходной таблице 1 запись с recno = 1
2. SELECT читает её и передаёт INSERT'у
3. INSERT вставляет запись, новая запись имеет номер 2
4. SELECT читает следующую запись, это новая запись с recno = 2. Он передаёт её INSERT'у

Так понятнее ?

Другие СУБД сначала выполняют SELECT, вычитывают полный резалтсет, куда-то его сохраняют и только потом передают INSERT'у на вход. Могу предположить, что такой алгоритм для них более естественный, т.к. потом всё-равно нужно записать в transaction log весь вставляемый набор.
IB\FB в этом не нуждается, поэтому ему не нужно, например, сохранять вставляемые данные неизвестно где, т.е. сама операция более эффективна.

vadiminfo nik_x
На выборках и апдейтах Оракле кроет ФБ процентов на 5-7.
На инсертах и делитах - Оракле отстает, причем безнадежно...
(9-ка эти операции много быстее делает, но - не сравнивал)
Скорость выполнения хранимых процедур - примерно одинакова.

Вам удалось получить сенсационные результаты. Борланд, если узнает, наверняка предложит Вам работу по настройке ФБ на тестах tpc за большие бабки, потому что сегодняшнее положение дел с этим не устраивает не только его, но и многих других, в частности andsm вообще из-за этого посатавил, похоже, крест на ФБ. С такими феноменальными результатами он оставит мало шансов (даже меньше чем Йексель с XML) и Скулю и DB2.
Но уже сегодня можно подавать в книгу рекродов Гиннеса.Странная реакция. Ничего сенсационного в этом нет. Это далеко не первое объявление подобного рода.

andsmЯ IB не изучал. Мне прислали gdb-файл (IB) с данными, я эти данные посмотрел и экспортнул в MSSQL. Зачем изучать продукт который:Не изучал - не стоит говорить того, чего не знаешь

andsm 1. Не подходит для тех задач которыми я занимаюсь. Например, легкость установки/размер 4 мегабайта - зачем это мне? Сейчас 5 админов осуществляют круглосуточный надзор за БД. Уж установить MSSQL они сумеют, я уверен И с учетом того что размер дискового пространства более терабайта место для SQL Server тоже найдется. База работает в режиме 24x7, FB/IB так умеет? По производительности - у меня вот уже полгода процентов 80, а в некоторые месяцы и все 100% времени уходит на оптимизацию, на работу по повышению производительности. Что у FB с производительностью? Сумеет выдержать 1000 довольно сложных транзакций в секунду, причем чтобы длительность каждой транзакции не превышала 250 мс?Не подходит - не пользуй. Зачем огульно хаять ?
Мне нравится эта фраза про повышение производительности. Она очень характерна. Или у вас за полгода настолько сильно изменилась БД, что приходится всё переделывать ? В любом случае это не характеризует ни FB, ни MSSQL - только вас.

andsm 2. Ненадежная. У меня business-critical application, и читая в форумах о проблемах с надежностью FB желание перенести все на FB не возникает. Выше были упомянуты еще и какие-то проблемы с бекапами. У меня бекап лога транзакций делается ежеминутно. Как на FB делать ежеминутный бекап на базе под высокой нагрузкой? FB поддерживает кластера?Ежеминутный бекап логов - я такого ещё не встречал. На FB можно делать хоть ежесекундный бекап, но смысла в этом, как и на MSSQL нет никакого. В FB2 есть мультиуровневый инкрементный физический бекап, аналогом которого в MSSQL есть одноуровневый differential backup

andsm 3. Нет поддержки производителя (может что-то и есть, но я не слышал). Поэтому обратиться в саппорт невозможно. Да ? Жаль Кузьменко не слышит. А этот сайт поиск не дал ? Впрочем поиска, насколько я понял, не было

andsm 4. Если подумать еще можно минусы привести, но и этого уже достаточно чтобы не изучать FB - как минимум до того времени пока FB не докажет что это продукт достаточно высокого класса.Это не нужно доказывать.

vadiminfo hvlad

"Не нормально" работает комбинация INSERT + SELECT :
1. пусть в исходной таблице 1 запись с recno = 1
2. SELECT читает её и передаёт INSERT'у
3. INSERT вставляет запись, новая запись имеет номер 2
4. SELECT читает следующую запись, это новая запись с recno = 2. Он передаёт её INSERT'у

Так понятнее ?

Это я давно понял. Не понимаю тока: это можно отнести к C в ACID или просто баг SQL инструкции. Особенность системы или ошибка разработчика. Потому что раньше разговор шел, что это не учет чего-то типа CS. Мы, вроде, выяснили с Вами, что CS не про то. Но о не неправильном выполнении инструкции SQL речи, вроде, не было. Вот про это что Вы сами думаете?К C это ника не относится, т.к. ни до, ни после тр-ции оно не нарушается. Я бы сказал, что это побочный эффект внутренних механизмов доступа, приводящий к неправильному выполнению конкретного оператора в конкретных условиях. Бороться с этим конечно будем, но приоритет невелик

vadiminfo hvlad
уровень определяется через блокировки кортежей, то его (определение) просто физически невозможно перенести на версионик FB, в котором отсутствует понятие блокировки записи.

Это как отсутствую блокировки? Совсем? Что ж там за модель транзакций? Временные отметки? Оракл тоже версионник, но блокировки там присутствуют. В общепринятом смысле - отсутствуют. Совсем.
Оракл не совсем версионник, у него версии не записей, а страниц, AFAIU.
Вот в Юкон ввели механизм очень похожий на IB.

Могу рекомендовать читать это и это ( вот общий список ), так как в 2-х словах я здесь не объясню. Не понятное - спрашивайте, завсегда помогу разобраться

vadiminfoА что FB вставляет в transaction log? Или как он накатывает закоммиченное, или откатывает незакоммиченное, если произошло падение БД. Т.е. что там с D в этом ACID у FB мы с Вами имеем?В IB\FB нет transaction log'а. И это не мешает ему иметь абсолютно нормальную D :)