в соседнй ветке я упоминал некоторые из недостатков Firebird, у Firebird маловато шансов. ASA наверника как блокировочник использовали, меньше всего трудозатрат наверно на db2 express выйдет, но с учетом популярности db2 в России может и не лучший кандидат.

pkarklin

Требований кроссплатформенности не вижу. Почему бы в список претендентов не добавить MS SQL Server 2008 Express Edition?!

IMHO, переход на него пройдет глаже, чем на Firibird и Oracle XE.
подозреваю автору оплата за ОСь вместо субд ничего принципиально не изменит.

2Senya_L

если у вас трудности в освоении бизисных вещей типа уровней изолированности транзакций, это не означает, что я фанатик ;)
если же вы вдруг за эти дни разобрались со основами rdbms, с интересом выслушаю какая именно фраза в том обсуждении вызвала столь бурную вантазию.

фокспро не супортит элементарных вещей типа ACID транзакции, не говоря уже о недостатках файл серверного подхода.
http://forum.foxclub.ru/read.php?29,186940,page=1
еще о сообществе фокспро:
/topic/189936&pg=29#2392495

2Eugenkru

не правда, в файл-серверной субд просто не возможно обеспечить ACID транзакцию бай дизайн. никакой патч не сможет создать фею на файл-сервере которая могла бы вычищать мусор погибшей транзакции. перечитайте тред из второй ссылки с 18 страницы и не повторяйте глупостей за вашими товарищами, не то закончится это тем же, что и в том топике ;)

глупости я увидел вот в этой фразе "Команды типа BEGIN TRANSACTION работают в Foxpro 9 безупречно."
что касается постановки задачи, то лично мне (как и подавляющему большинству разработчиков) необходимо чтоб стейтмент "update table1 set filed1='Shit' " мне гарантировано или проапдейтил всю таблицу или не проадейтил ничего (сообщив об ошибке). конструкция BEGIN TRANSACTION в foxpro 9 такого гарантировать не может, посему использовать такой SQL движек в 21 веке странновато по меньшей мере.

Eugenkru
Yo, у тебя в голове каша! ))))
1. Движок SQL и механизм BEGIN TRANSACTION - это же совершенно два разных понятия!
Не надо их путать!
дитетко, begin transaction это не механизм, а синтаксис. причем в случае с фокспро эта конструкция имеет столько же общего с понятием транзакция сколько бумажный самолетик с Су-35. поскольку стандарт ANSI SQL описывает понятие транзакции, большинство SQL движков такой механизм имеют и только у фокспро имеют его ...
Eugenkru
2. Я просил описать конкретную пользовательскую постановку задачи (т.е. что ввести, куда ввести, где расположены базы и что получить) а не игрушки с таблицами!

что куда вводить нуна я тут рассказывать стесняюсь, а вам пора и самому разузнать
а вот в плане транзакций я с задачами где можно без ANSI транзакций обойтись не пересекался, потому любая задача обновляющая более двух записей годится.

Eugenkru
Есть понятие буферизации данных. Сделай себе ради Бога буферизованную таблицу и пиши туда что хочеш! Для этого тебе вообще не нужны транзакции! Есть же буферизация Yo mae! )))

зачем мне туда что-то писать ? простите, но мне дбф нафиг не нужен, а фокспрошной буферизацией я еще в foxpro 2.0 накушался, когда там SQL и транзакциями еще не пахло. больше мне не нада ...

Eugenkru
3. Что же касается BEGIN TRANSACTION то она работает безупречно! Ну а если тот товарищ из фокс-клуба пытался в мэнэджэре задач виндовса сорвать работу фокспро, то пусть он играется в игрушки дальше! Но даже в этом случае базы данных не повредятся. Информация может быть частично потеряна но только в тех записях где не был закончен ввод! Комадна FLUSH быстренько сбрасывает данные на диск, если кто то хочет подстраховаться в процессе ввода! )))
открою тайну, тот "товарищ" енто я и есть ;)
так вот, вижу вы уже прошли огромный путь (для лисовода) до понимания, что до END TRANSACTION обновление происходит буферов, которые по команде FLUSH или END TRANSACTION сбрасываются в дбф, отлично. теперь попробуйте осознать, что FLUSH как и END TRANSACTION быстренько ничего не сделает. FLASHнуть одним чихом все изменения виндовс не магет, головка HDD тупо не резиновая. поэтому процесс сброса содержимого буферов в дбф файлики в полне может затянутся и может неожиданно прерваться (ребутнуться клиент, отвалится связь с файл-сервером и т.п.). вот и получается, что в результате в дбф записано лишь пол транзакции ...

транзакция рулез и я пророк его
Ё в натуре