Firebird crash

Здравейте, след няколко часови непрекаснати инсъртове в базата в един прекрасен момент сървъра забива и в Event Viewer-a излиза това чудесно съобщение:

The description for Event ID ( 281 ) in Source ( FirebirdGuardianDefaultInstance ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Abnormal Termination: C:\FB\bin\fbserver.exe: terminated abnormally (4294967295)

Как да не му се нарадваш като го гледаш. Та така след като се рестартира сървъра всичко продължава отново докато след няколко часа пак не видим добре познатото ни вече съобщение.

Firebird 1.5.3
Delphi 7
dbExpress компоненти за връзка с базата данни

Ако някой се е сблъсквал с този проблем ще съм му благодарен да сподели мнение. Благодаря предварително.

Използваш ли някакви UDF функции? Вярно, има някои заявки, които могат да убият Firebird сървъра, но не мисля че случаят е такъв (ти казваш, че само инсъртваш). Имаш ли някаква по-сложни заявки, които изпълняваш - като например в тях да има джойнове между таблици и вюта, сторед процедури и т.н., някакви сложни вложени селекти и изобщо нещо по-различно от тривиалните заявки?

Значи ето цялата картинка:
Към едно .fdb е вързана въпросната програмка, която прави инсърт и ако върне дублиране на ключа прави ъпдейт. Това е всичко което прави тази програмка, но го прави без прекъсване. Освен нея има една друга програма към същата база, която от няколко клиентски компютъра прави елементарни селекти (не са сложни има по един два джоин-а). Нямам стор процедури, нямам тридери и не използвам UDF-и. Ако смяташ, че някой от селектите ми събаря сървъра ще се разровя да ги прегледам. На едно място прочетох човек с подобен проблем, след като си сменил Firebird-a от Super server на Classic server се оправило, но при мен продължава проблема, пък и смятам че това е заобикаляне на проблема. Ако ти трябва още някакво инфо питай.

Вж. това дали няма да те насочи къде да ровиш

Възможно е да е и проблем в сървъра. Със стабилна версия на 1.5.3 ли си? Не си с някой release candidat предполагам? Сложи някоя 1.5.2-ка и виж дали и с нея ще се държи така. Ако това не е продакшън система можеш да опиташ и с 2.0 beta-та.
А иначе не ми харесва идеята да предизвикваш грешка и да гледаш дали ще се случи. Във всички случаи е по-добре вместо това да провериш дали записа го има или не и след това да го вмъкнеш или ъпдейтнеш. Ако те притеснява бързодействието, че ще изпълняваш 2 заявки - направи го със сторед процедура, че даже и с курсор.
Другото, което исках да те пита - как управляваш транзакциите? След всеки запис ли къмитваш и ако да - с Ccommit или с CommitRetaining?

Правих варианти да commit-вам на 200 и на 2000 записа, но резултата е един и същ. Използвам commit.

Ами явно остават вариантите да смениш версията на сървъра или да си смениш имплементацията.
Иначе проблема е интересен... Можеш ли да направиш един тест кейс (базичка и малко програмче), което да го възпроизвежда? Би ми било интересно да го проуча.

Аndrew проблема изглежда е точно в имплементацията. Направих вариант в който не чакам да ми върне key violation за да направя ъпдейт и всичко е ок засега. Възможно е сървъра да забива точно заради многото key violation-и. Мерси за съдействието.

Напълно възможно. Не карай сървъра да те "псува" като част от алгоритъма на приложението ти. При мен или спира или "забива", въпреки че си има и проблеми - като например на 1.5.2 версията, колегата спря сървъра като му пусна заявка от 27 униона със селекти на 5-6 полета, а сигурно има и други такива ....

Вж това Тесты вариантов реализации проверки существования записи при ее обновлении