Здравствуйте!!!
В данной теме речь идет о БД которая прилагается к системе К3-мебель 6.4 и все манипуляции с Этой БД (Расчёт стоимости заказа и пр.) производятся непосредственно в Access`e единственное что делает приложение К3-мебель 6.4 (3D-ядро) это отправляет заказ в БД после его обработки. Там очень большой поток данный пердаётся.

Хотел Узнать есть, ли у кого-нибудь опыт создания так сказать псевдо-серверной системы (чтобы заказы с двух и более клиентских компьютеров собирались в одной БАЗЕ, кто знаком со структурой к3-базы данных знает, что вся информация о заказах хранится в файле-базе tCustomV6.mdb).
Тут есть 2 пути:
1. положить файлу-базу tCustomV6.mdb на общий ресурс на файловый сервер и связать все её таблицы с каждым клиентом. В этом случае есть проблема присвоения и переопределения айдишников плюс к этому в этом файле-базе содержатся другие уже мои вспомогательные таблицы которые тоже учавствуют в процессе расчёта заказа.
2.Создание разделённой БД, т.е. файл-база tCustomV6.mdb у каждого клиента остаётся своя, а на сервере содержиться дубликат всех таблиц базы tCustomV6.mdb и туда просто по окончании оформления заказа он синхронизируется БД на сервере, но тут естественно возникает проблема дублежа, да это проблема может быть решена внимательностью при импорте-экспорте заказов, чтоб на сервере всегда находилась более новая версия заказа, но перекладывать эту проблему на проектировщиков не очень рационально, ведь проектировщик может и забыть синронизироватся.
Всем спасибо, с нетерпением буду ждать совета.

Если сервер есть -- то система вполне серверная. Другой вопрос, что это не сервер баз данных можэт быть, но это не суть.



Не страдайте фигнёй, право слово. Поставьте нормальный сервер СУБД (Postgres, MySQL, Firebird, MS SQL Server, их есть в общем) и связывайте таблицы с ним.



Нет, проблема цэлостности и достоверности распределённых данных не можэт быть решэна только обучением персонала. Хотя во всех решэниях обучение персонала будет присутствовать.

Да, вариант 0.5 -- положыть эту tCustomv6.mdb на общий ресурс на файловый сервер и открывать оттуда.

Я ни хрена не понял... но...

Речь идёт о том, что есть некое приложение, которое использует Аксессовскую БД в качестве хранилища данных. Это понятно. Фраза, что "все манипуляции с Этой БД (Расчёт стоимости заказа и пр.) производятся непосредственно в Access`e единственное что делает приложение К3-мебель 6.4 (3D-ядро) это отправляет заказ в БД после его обработки" непонятна в принципе. Речь о том, что для работы комплекса требуется установленный MS Access? и БД запускается в нём на исполнение? а сама программа не более чем визуализатор плюс мелкие фенечки?

Впрочем, ладно.

В теории есть не два, а три пути. Может, даже четыре. Или даже пять.

Путь 1. Файл базы данных выкладывается на сервер, стартует оттуда (когда нужно стартовать именно его), программа настраивается на работу с ним.

Путь возможный, но... БД Аксесса используется также и как кэш. т.е. каждый клиент будет резервировать там для себя temp-пространство. C учётом того, что по достижении размера в 2 Гб файл базы рушится - уже стрёмно. А если, не дай бог, один клиент нештатно свалится - разрушение БД весьма вероятно.

Путь 2. Выполняется разделение БД. Мастером. Получаем две БД - интерфейсную и с данными. Интерфейсные раздаём пользователям, а базу с данными кладём на сервер.

Путь возможный, но... БД Аксесса использует общий файл блокировок. Если там и правда большой поток данных - всё будет работать достаточно медленно, и при сливе одним АРМ данных остальные будут конкретно тормозить. Ну и при сбое в процессе изменения данных опять же база может отправиться к праотцам.

Путь 3. Выполняется подготовка БД к репликации и создание реплик. Мастер-реплика хранится в надёжном месте, а слейвы раздаются по рабочим местам. Регулярно выполняется сбор слейвов, синхронизация реплик, и обратная раздача. Из минусов - синхронизацию придётся выполнять вручную, иногда возможны коллизии, и их придётся разводить тоже "руками", изменения от одного клиента буду попадать к остальным только после репликации. Ну и способ вообще неприменим, если на клиенте (неважно, в БД или в программе) реализована программная логика нумерации чего-либо.

Путь 4. Установка MS SQL. Перенос таблиц на сервер и подключение связанных таблиц через ODBC-драйвер. Аналогично по сути варианту 2, но без большинства проблем, присущих этому варианту. Впрочем, не факт, что оболочка и программный код БД могут работать со связанными ODBC-таблицами.

Путь 5.  Возможный лишь теоретически. Установка MS SQL. Конвертация БД в проект. Аналогично по сути варианту 2, но без большинства проблем, присущих этому варианту. Впрочем, не факт, что программный код БД может работать со связанными ODBC-таблицами, а оболочка вообще сможет работать с проектом.