Если нужна БД то пиши под MySQL. А всякое лисятничество это из области плясок с бубном. Я сам ничего против лисоведов и их продукта не имею но файл-сервер технологии это вчерашний день. Если предприятие представляет собой шаражку на 20 человек смело можешь под лисицу или Tripper писать, только сразу договорись с начальством по поводу того, кто будет ответственнен если в БД глюки обнаружиться или она просто полетит. Если не хочеться в будущем иметь проблем ставь нормальную базу. Лучше сейчас потратить немного больше времени на разработку, чем в будущем иметь проблемы с целостностью данных или восстановлением БД. Я понимаю, что это не звучит но прочтите пожайлуста следующую печальную историю. В свою бытность приходилось поддерживать БД для одной конторы написаную под Btrieve одну из самых известных ФС БД. Не могу высказать претензий к работе на 20 коннекшенов к базе одновременно - все работало как часы, но ... В конце месяца приходилось делать огромную кучу проводок документов, каждая из которых порождала несколько документов. Итак ситуация - является коммисия к нам, ей треба информация по предприятию. А в этот день как назло сеть сбоила, народ запускает приложение, оно подвисает и его убивают. В итоге получаем проблему с переплатой или недоплатой по определенным счетам, плюс ко всему баланс не идет правильно, а всю потому что ФС не поддерживает правильно транзакции. Начальство звереет и вздрючивает разработчиков не по-детски. В итоге все свободные разработчики сидят и чистят базу за текущий день ручками. Через день новая напасть - сыпется база. Так как у ФС прекрасная возможность восстановления БД, то делается следующая вещь: восстанавливается информация за предыдущий день и делается применение журналов к базе :) - все разработчики, плюс отдел бухгалтерии сидят и руками вводят информацию. Начальство снова звереет и достается на орехи бедным разработчикам. Через пол-года снова подобная ситуация. А потом весьма приятный переход с Btrive под мракософт SQL сервер, после которого отдел разработки потерял остаток человеческих черт.
Так что если хотите писать под ФС - пишите на здоровье, только задумайтесь готовы ли вы к такому геморою. Может сразу лучше писать под что-то толковое, чем потом стучать в бубен и делать 3 раза КУ, чтобы поправить базу?

Да у нас тоже ничего раньше подобного не было а потом, как народу в базе прибавилось то все и стало глючить. А работало все на Novell+Btrieve. Когда нет нормальных средств резервирования и восстановления базы, то весьма проблематично что-то сделать. А по поводу транзакций Btrieve воспринимает транзакцию в стиле одна запись в одном файле. А вот если в 2-3 файла начинаем писать или много записей в один файл вставлять, а прога отрубается, то получаем фигню с данными. И к сожалению никакие упсы и райды не помогают. Потому и перешли на мракософт.

Можно и из лисицы состряпать что-то удобоваримое. Нам тоже пришлось искусственно реализовывать механизм поддержки длинных транзакций под Btrieve. Только зачем мучаться, если эти средства давно реализованы в полной мере в нормальных СУБД. Смысла изобретать велосипед я не вижу. Разработчик должен думать о реализации бизнес-логики, а не о реализации всяких системных приблуд. К тому же Urri привел пример идеальной системы, где все защищено и работает абсолютно стабильно. А вот если что-то бузить начинает, то тогда туши свет...