wadmankdvзачем делаете перевод прикладного приложения с embedded на 64 бита?
Модно, стильно, молодежно. Все-же переходят.

Есть два простых совета по использованию FB:
1. Не используйте 32-битные сборки сервера и клиента.
2. Не используйте встроенный сервер.

CyberMaxКоваленко Дмитрий1. Не используйте 32-битные сборки сервера и клиента.
Можно поподробнее?
Какие конкретно подробности ты хочешь услышать? Типа ошибка в такой-то строке?

При "неожиданных" проблемах (например, при исчерпании ресурсов) сервер и клиент наступают себе на хвост и падают/зависают.

На 64 битах, этот момент можно отложить на некоторое время.

---
Причем это проблема не только FB. Она вообще глобальная. Потому что, @#!, писать надежный код очень дорого.

qwer098Коваленко ДмитрийЕсть два простых совета по использованию FB:
1. Не используйте 32-битные сборки сервера и клиента.
2. Не используйте встроенный сервер.
И все-таки, почему?

1. Я описал выше. И неоднократно ругался здесь . Через месяц будет год как я окончательно забил на 32-битные компоненты сервера.

У меня недавно навернулся и 64-битный FB3 (в системе ресурсы закончилась - один драйвер дескрипторы не освобождал). Правда тогда упало очень много всего интересного ...

Так что, конечно, 64-бита не панацея.

2. У таких вещей (многопоточные DLL) должна быть пара функций - инициализация и деинициализация. Как, к примеру, у WinSock. Инициализации у встроенного сервера нет (?). А деинициализация есть. Если у тебя приложение с одним выходом, то без явной инициализации жить можно. Если что-то более сложное (оформленное в виде DLL) - то скорее всего возникнут проблемы с определением момента вызова деинициализации.

1+2. Если у тебя, при нехватке ресурсов, навернётся приложение со встроенным сервером, то, скорее всего, база будет повреждена.

----
На "нересурсоемких" задачах можно использовать что угодно :)

----
И да, вот что я пока могу (осторожно) сказать хорошего про FB(3) - при нехватке места на диске он не падает и базу не портит.

kdvУ него там какие-то специфические случаи, которые в остальных 99% не имеют смысла.
Этот специфический случай называется "нагрузочное тестирование", через которое в течении месяца (как гласит предание) проходили релизы InterBase. И, наверное, должны проходить релизы Firebird. Но факты говорят об обратном.



hvladКоваленко Дмитрий2. У таких вещей (многопоточные DLL) должна быть пара функций - инициализация и деинициализация.Это можно обсудить.
По-моему надо просто начинать трясти. Правда, я предлагаю сразу, лучше вырвать с корнем и посадить дерево заново :)

Dimitry SibiryakovКоваленко Дмитрий Если что-то более сложное (оформленное в виде DLL) - то скорее всего возникнут
проблемы с определением момента вызова деинициализации.

Ой да какие там проблемы? MSDN прочитать да руку от лица суметь отлепить?..

Ну и чего ты не помог в 2012-ом разрабам FB, когда они прикрутили рабочий поток в fbclient.dll, год с ним помучились, а потом открутили обратно?

Им так тебя не хватало.

rdb_devКоваленко Дмитрий2. У таких вещей (многопоточные DLL) должна быть пара функций - инициализация и деинициализацияНафига аж целую пару функций?! DLL всю жизнь обходились одной функцией и для инициализации и для деинициализации.


Месье продает серверные компоненты, оформленные в виде динамически загружаемых модулей?

Можно ссылочку, для ознакомления с достижениями?

hvladКоваленко ДмитрийЭтот специфический случай называется "нагрузочное тестирование", через которое в течении месяца (как гласит предание) проходили релизы InterBase. И, наверное, должны проходить релизы Firebird. Но факты говорят об обратном.Всё протестировать невозможно, маемо те, шо маемо (ц) :

Я вот одного тогда понять не смог. Подключаемся к серверу, отключаемся. Второй раз подключаемся (через пару минут) - получаем ошибку подключения. Полгода до релиза, полгода после релиза.

Вот как такое можно прошляпить с такой толпой народа?

Собственно, претензия даже не к вам, а к толпе.
[spoiler] Дальше я вырезал, чтобы сильно тебя не расстраивать. Но видео оставлю, понравилось.