Firebird не отпускает файлик базы.

[Merlin]

И что ты взъерошился на меня без повода?! Проблема есть, я её пытаюсь решить для себя, вылез сюда за помощью, все люди по людски разговаривают, а ты зачем-то ворчать пытаешься...

Выключай флеймилку!

Мир и дружба Насчёт обнародования глюка с неотпусканием файла - спасибо. А в процесс разработки embedded совать - ну не дело это. Выигрыш перед супером в смысле расхода RAM при загрузке dll вместо exe - полная фигня, код-то один и тот же, просто сервер с клиентом в один флакон слиты. А гемор приличный. И в последние несколько дней таких постов просто косяк идёт - хочу чтоб embedded был не embedded, а что-то такое что мне хочется и кажется лучше. А если человек слишком в этой колее завязнет, то потом его очень трудно вернуть на правильную дорогу. Твой-то пост действительно самый разумный из этой серии, просто уже смешно стало.

[Pavel Egorov]

Мир!

Только я же уже писал, что дело не в Embedded. С классикой та же фигня.
А причина по которой меня Embedded привлёк очень проста.
У нас все проекты (много десятков) объединены в один большущий солюшен. И при компиляции запускается юнит-тестирование. Хочется в юнит-тестах для своих проектов, которые используют nHibernate полноценно его (nHibernate) протестировать. Но при этом есть объяснимое желание: чтобы для того, чтобы успешно скомпилировать солюшен, не надо было бы ставить на комп какую-то СУБД. Людям, которые работают над другими проектами из солюшена эта СУБД вообще говоря никуда не упёрлась, а полную компиляцию уметь запускать очень хочется. Особенно, когда очщий кусок кода правишь.

А для nHibernate в общем-то пофигу с какой СУБД работать. Поэтому появилось желание взглянуть на FB Embedded, который установки не требует. И всё у меня с ним хорошо получилось, кроме вот этой банальной вещи - не могу удалить за собой тестовую базу

А почему Embedded в процессе разработке в нашем случае - это плохо, я всё ещё не понимаю. Это что, заповедь? Или всё таки есть реальные причины?

[Merlin]

Я ж уже говорил. Монопольный однопользовательский захват файла базы при коннекте со всеми вытекающими. Ну и трассировать программу начнёшь - сам всё поймёшь

[kdv]

А почему Embedded в процессе разработке в нашем случае - это плохо, я всё ещё не понимаю. Это что, заповедь?

от дикие люди ... среды разработки от Borland характеризуются тем, что позволяют разрабатывать софт используя "живые" данные. То есть, коннект к базе производится прямо из компонент среды, в design-time. Так? Теперь запускаем из среды же приложение в режиме отладки.
Получаем ВТОРОЙ экземпляр exe, который коннектится к той же базе.

Если сервер БД - Embedded, то разработчик начинает недоумевать, почему же приложению не дают законнектиться к БД. Начинает закрывать коннект в дизайн-тайме, и осуществлять другой разнообразный гемор.

В случае с .Net, кстати (думаю как и с Java VM) вполне может быть что такой фокус пройдет. Т.к. коннектится к базе и в среде и отдельно не отдельный exe, а "сам .Net". Но как ты видишь, наблюдаются какие то другие глюки.

Ты, кстати, procmon-ом или filemon-ом посмотрел, кто же именно держит файл базы открытым? Это же, блин, за 2 минуты можно сделать.

[Pavel Egorov]

В общем так.
В случае с классикой всё решилось вот так:

Код: Выделить всё

			FbConfiguration configuration = new FbConfiguration();
			configuration.ConnectionString = connectionString;
			configuration.DatabaseShutdown(FbShutdownMode.Forced, 0);
			Thread.Sleep(1000);
			FbConnection.DropDatabase(connectionString);

Тут файлик базы держал fb_inet_server.exe. Без загадочной DatabaseShutdown ничего не работает. Без задержки - тоже

В случае с Embedded базу держит само выполняющееся приложение. Получается примерно такой лог:
- приложение начало работу
- открыли файлик
- чего-то поделали
- схлопотали SHARING VIOLATION
- подождали пару секунд
- закрыли файлик
- приложение завершило работу

Увеличение задержки с одной секунды до 10 ситуацию не меняет.
Больше похоже на особенность самого FB Embedded.

Никто не проверял IBX компоненты на такую же багу?
А-то неохота Delphi устанавливать, только чтобы узнать чья именно это особенность .NET Provider-а или FB Embedded.

UPDATE:
Поясню по поводу SHARING VIOLATION. Его схлопотал не fb, а моя программа, при попытке удалить файлик с базой уже после того, как её якобы уже Drop-нули. То есть drop уже якобы выполнился, но файлик всё ещё на месте и при этом доступа к нему нет.

[Merlin]

Сие значит, что "закрыли файлик" не выполнялось. В твоём коде мимо прошли или провайдер раком встал после AV - отсюда не видать. Embedded ни при чём - раз процесс классики тоже остаётся, знач клиент не закрывает корректно соединение и завершается по типу трёхпальцевого салюта. Если к классике соединялся через TCP (localhost), то через некоторое время (определяемое настройками so_keepalive) он почувствует что клиент издох и самоликвидируется. Что с этим в локальном коннекте - не интересовался никогда ибо не нада. В IBX такой проблемы нет, у него проблема в случае потери коннекта по поводу смерти сервера или сетки.

[Pavel Egorov]

Проблема полностью решилась. Как это часто и бывает, это оказалась фича, а не баг

Надо было всего лишь подкрутить строку подключения добавив туда "Pooling=false". По умолчанию он true, а когда он true, то закрывающиеся соединения на самом деле не закрываются а складываются в пул. Собственно из-за этого и проблемы были.

[Тяжёлов Глеб]

В приложении несколько тестов. Перед каждым тестом база чистится и заполняется заново. Для отображения объектов в базу, пользую NHibernate.

Так вот, не смотря на выключение пулинга, некоторые из тестов случайным образом выдают исключение - object <имя_таблицы> is in use.

Всё, на что хватило фантазии, уже пробовал. Помогает только Thread.Sleep в [SetUp] теста NUnit'а.

Я, правда, тоже извращаюсь с Embedded, но установка ServerType в 0 не решает проблему.

Кривые руки конечно не исключаю, однако целительная сила Thread.Sleep, указывает на то, что нечто держит таблицу. И в этом случае руки наверное не причем

Есть какие-нибудь идеи, господа?

PS Версии Firebird server, embedded и .net клиент, на настоящее время, последние.