wamacokdvэто не многопользовательская БД. там монопольный write. Грубо говоря, это файл-сервер, такой же как и access.Так поэтому и сравниваю ACCESS и SQLite, т.к. не серверы.....
Я же написал, что сервер не предлагать. Сам понимаю, что поставил бы сервер и не знал бы бед, но задача именно
такая! Вот и интересуюсь....А Вы можете озвучить внятную причину, по которой категорически нельзя использовать сервер баз данных для этой задачи?
wamacoПросто чаще и больше работать будет один пользователь, но иногда возможно подключение еще одного-двух пользователей для
просмотра отчетов и иногда правки нескольких справочников. И так всегда будет, масштабирование невозможно!Варианты "только два пользователя" и "не придвидится масштабировать" - это очень необоснованно и крайне невнятно...
wamacoНадо будет больше, решение будет другое, более дорогое и традиционное (Клиент-Сервер, Трёхзвенка или еще чё-нить).
Сейчас так и никак иначе! "Дорогое решение"?! И в чем же заключается "дороговизна" этого "традиционного" решения?
Вы вообще в курсе, что существует "несметный" выбор среди одних только бесплатных серверов БД - это даже не рассматривая бесплатные экспресс-версии "больших" СУБД?
"True universal open source database" firebird (с учетом планируемого использования Delphi) - это Ваш "правильный" вариант.
wamacoВыбора всего два: Sqlite или Access! Да. Это - "по-нашему": сначала создать себе проблемы, а потом героически их преодолевать...

kgb ussrУ нас в одном отделе только акцесс используют.
Адские задачи решают.
Адские.:) Верю!
Некоторое время назад одна "адская задача" проходила и через мои руки - потом ее мигрировали на не-access...

При использовании access'а не составляет проблемы подключаться к практически к любому внешнему источнику данных...