Спорно, Влад. Навалом случаев, когда надо коммитить половину. Скажем, бежим на клиенте по некоторому длинному резалтсету, на котором надо выполнить однотипную операцию. На трёх записях получили конфликт, да и фиг с ним - коммитим, рефрешим, извещаем юзверя, хочет - повторяет попытку только с ними, хочет - в другой раз. Однако, если б на релизных отпатченных IB творилась такая фигня, они давно были бы на помойке вместе с аффтарами. Такшта имхо либо накосячили упёртые гоношистые ребята таки с миксом DDL-DML в одной транзакции, либо железо дырявое.hvlad писал(а):Нет. Делать роллбек при ошибках, а не надеяться на коммит половины тр-ции.PostMan007 писал(а):Выход - делать коммит после инсерта (если можно)
Умирают индексы и внешние ключи
1. savepoints в ХП ? у меня 2 процедуры одна вставляет записи вторая делает проводку документа, если из делфи не вопрос закомитил после вставки и порядок, а если какой-нибудь студент запустит это из консоли, то все индексы порушены.1. По begin..end см. "savepoints", "system savepoints". Проблема явно в них.
2. Хамите, парниша? Можешь не писать - не пиши.
3. Делать можно всё. Ты явно нарвался на какой-то глюк (или "особенность") работы IB. Глюки не документируют, их исправляют. И посоветовали тебе не "совсем не делать", а "так не делать, обойти проблему".
2. Парниша? - что за обращение, с южного рынка? какое предложение такой и ответ, есть логика надо написать именно так.
3. Обход уже сделан см. пункт 1, но это не решает вопроса. Получается после исключения индексы не "откатываются", точнее так при одних условиях откатываются при других нет.
Такшта имхо либо накосячили упёртые гоношистые ребята таки с миксом DDL-DML в одной транзакции
опять прослеживаются мотивы какого-то рынка
Железо нормальное, сделайте так у себя в любой новой базе и будет то же самое, всего то создать 2 таблицы и процедуру.либо железо дырявое
Вот это уже полезная информация, тогда я думаю, что это чистый глюк IB и надо сообщать об этом баге.В FB, кстати, такой проблемы нет. Я уже намекнул, что похоже на баг в IB.
[/quote]
так, участникам форума Felix1978 и PostMan007 ПРЕДУПРЕЖДЕНИЕ.
Теперь по поводу проблемы. Воспроизводимо? Наверное, да (я еще не проверял). Считаете багом? Пишите в трекер Codegear. Не умеете формулировать или писать по английски - скажите сразу, я это сделаю за вас.
Если вы нашли баг - надо о нем сообщать разработчикам, а не выпендриваться. Здесь вам могут дать только советы как ОБОЙТИ эту проблему. И такие советы дали. Более того, если это подтвержденный баг, считайте что в 7.5 это вряд-ли уже исправят, зато могут исправить в IB 2007. И то, только через некоторое время, после того как об этом баге сообщить разработчикам. И пока они будут чинить баг, вам придется обходить его.
Надеюсь, я ситуацию понятно объяснил?
p.s. Вообще делать update одной и той же записи в одной транзакции не рекомендуется, как минимум из-за производительности. Что в FB что в IB. О том, что и как делает в это время сервер, есть статья www.ibase.ru/devinfo/test3.htm (еще одна в самом начале).
что и делаю. Будете еще выступать - отключу. Почему - см. дальше.и модератору, если он не слеп на один глаз, следовало бы обратить внимание и выставить предупреждение сначало на этот пост.
Теперь по поводу проблемы. Воспроизводимо? Наверное, да (я еще не проверял). Считаете багом? Пишите в трекер Codegear. Не умеете формулировать или писать по английски - скажите сразу, я это сделаю за вас.
Если вы нашли баг - надо о нем сообщать разработчикам, а не выпендриваться. Здесь вам могут дать только советы как ОБОЙТИ эту проблему. И такие советы дали. Более того, если это подтвержденный баг, считайте что в 7.5 это вряд-ли уже исправят, зато могут исправить в IB 2007. И то, только через некоторое время, после того как об этом баге сообщить разработчикам. И пока они будут чинить баг, вам придется обходить его.
Надеюсь, я ситуацию понятно объяснил?
p.s. Вообще делать update одной и той же записи в одной транзакции не рекомендуется, как минимум из-за производительности. Что в FB что в IB. О том, что и как делает в это время сервер, есть статья www.ibase.ru/devinfo/test3.htm (еще одна в самом начале).
повторил. Глянул сразу после commit статистику IBA2.
у таблицы A в индексе по FK (B_ID) ключей стало - 0. При оставшейся одной записи.
создал репорт:
http://qc.codegear.com/wc/qcmain.aspx?d=60851
UPD: кстати. совет "не делать больно", т.е. не делать такие апдейты (парой) да еще с exception - и есть workaround, т.е. путь обхода проблемы. Проблема сложная, понять ее хотя бы приблизительно можно только если
1. сообразить, что insert, update, update выполняются над одной записью в одной транзакции
2. прочитать статью в ibdeveloper, ссылка на которую в test3.htm, в первых двух абзацах.
3. учесть, что проблема экзотическая, и до сих пор вроде-бы никто на такое не наталкивался. Это намек на экзотичность кода. За багрепорт, конечно, спасибо, а вот все препирательства того не стоили.
у таблицы A в индексе по FK (B_ID) ключей стало - 0. При оставшейся одной записи.
создал репорт:
http://qc.codegear.com/wc/qcmain.aspx?d=60851
UPD: кстати. совет "не делать больно", т.е. не делать такие апдейты (парой) да еще с exception - и есть workaround, т.е. путь обхода проблемы. Проблема сложная, понять ее хотя бы приблизительно можно только если
1. сообразить, что insert, update, update выполняются над одной записью в одной транзакции
2. прочитать статью в ibdeveloper, ссылка на которую в test3.htm, в первых двух абзацах.
3. учесть, что проблема экзотическая, и до сих пор вроде-бы никто на такое не наталкивался. Это намек на экзотичность кода. За багрепорт, конечно, спасибо, а вот все препирательства того не стоили.