| |
|
|
| | Здравствуйте!
Очень нужна помощь еще в одном вопросе.
Для базы данных Access нужно организовать передачу данных между несколькими компьютерами. Так как компьютеры не связаны между собой локальной сетью и не имеют подключения к интернету, связь между ними реализуется только с помощью флешки.
На одном компьютере находится база данных, с которой работают, в которой сть формы, таблицы и так далее, в ней же будет находиться вся информация. Нужно сделать так, что бы на флешке на другие компьютеры можно было переносить что-то типа пустых форм, таких же как в базе, что бы пользователи этих компьютеров заполняли эти формы и возвращали флешки с заполненными формами на основной компьютер, где хранится база.
Пробовала сделать все это через репликацию и так называемый "Портфель", но носить на флешках практически точную копию всей базы с таблицами, запросами и т.д. как-то не очень удобно.
Может быть есть какой-то другой выход из этой ситуации. Подскажите пожалуйста, что тут можно придумать или что я сделала не так | |
| |
| |
| |
|
|
| | А не лече ли сделать на клиентах этих пользователей функцию выгрузки данных даже в тот же Excel. Потом забирать его и уже на компе где храниться БД сделать запрос на добавление из этого файла Excel в вашу базу? | |
| |
| |
| |
|
|
| | mulrus
ПРоблема в том, что выглядеть все это должно максимально просто, если дать пользователям переферийных компьютеров таблицы Excel, то проблема не будет решена, к сожалению... Как сказали мне, когда ставили передо мной задачу создания БД и соответствующих "автономных форм" для удаленных компьютеров, "делается все в расчете на дураков, то есть все должно быть максимально просто и понятно" | |
| |
| |
| |
|
|
| | Если движение информации возможно только в одну сторону, т.е. от периферии к центру, и записи уникальны для каждой точки (т.е. одни и те же данные не могу изменяться в разных местах), то все достаточно просто.
Создаются базы по количеству точек +1 (для центральной)
Для идентификации записи используются либо коды репликации (вместо последовательного счетчика) либо пара полей (счетчик+поле уникальное для каждой точки), тогда каждая записи в центральной базе будет определяться парой полей.
В базах точек делается процедура выгрузки данных (либо всех, либо только измененных/добавленных/удаленных с последней выгрузки)
формат выгрузки роли особой не играет, но при небольших объемах, я бы предложил MDB
В центральной базе делается загрузка (все это можно сделать c docmd.transferdatabase)
Самое сложное это разграничить возможность изменения одних и тех же данных в разных местах. и определить последовательность обновления/добавления/удаления данных, так что бы "потомки" добавлялись после "родителей", а удалялись раньше
Есть еще такой вариант как отсоединенные рекордсеты... но это сложнее с точки зрения реализации. | |
| |
| |
| |
|
|
| | osmor
Не поняла, как сделать процедуру выгрузки и загрузки данных?
Еще вопрос: для реализации этого метода база должна быть как на центральном, так и на переферийных компьютерах? | |
| |
| |
| |
|
|
| | Я не знаю как вам рассказать как сделать процедуру выгрузки, это вопрос из серии как построить дом.
создаете запросы которые будут отбирать нужные вам данные из таблиц, и выгружаете данные отобранные этими запросами во внешний файл с помощью docmd.transferdatabase
если нужно выгруженные данные удаляете или помечаете как выгруженные
потом полученный файл несете на компьютер где находится центральная база и там загружаете с помощью запросов на добавление, обновление, удаление....
Как еще объяснить, я не знаю, если только самому написать эти процедуры (не воспринимать как намек)
База должны быть везде, вот данные в ней могут быть (да и будут) разные. | |
| |
| |
| |
|
|
| | Спасибо, наверное это хорошая идея, подумаю, попробую.
Может есть еще какие-то варианты? | |
| |
| |
| |
 175 Кб. |
|
| | Ну вот выдрал из старой базы.
Суть такова:
есть несколько рабочих мест менеджеров, они только регистрируют договоры, но ничего не знают о финансовой стороне дела
База OrdersLigth00.mdb
есть одно рабочее место фин. директора который занимается финансами к договорам которые зарегистрировали менеджеры.
База OrdersFin00.mdb
У каждого менеджера свои договоры.
По ТЗ фин директор зашифрован так что данные к нему могут попадать только через дискету.
Данные "движутся" в одну сторону, т.е. от менеджеров к фин. директору. Те изменения которые внес фин директор "остаются" у него и менеджеры о них не узнают.
Работает так.
Во всех таблицах которые должны обновляться есть поле dtUpdate ("Дата обновления") как только запись изменяется, это поле заменяется на текущую дату
Есть служебная таблица (tblStartUp) в которой фиксируется дата последней "выгрузки" данных.
Есть набор запросов отбирающих данные из таблиц с датой изменения dtUpdate больше даты последней выгрузки
Есть служебная таблица tblExport которая определяет в каком порядке нужно выполнять запросы и как будет называться таблица в файле выгрузки.
Для выгрузки данных в базе менеджера (OrdersLigth00.mdb) запускается форма frmExport, в ней кнопка которая выгружает данные изменившиеся с даты последней выгрузки, называя файл UpDD_MM_YY.mdb (т.е. сегодняшней датой)
В этом примере будет создаваться в корне диска С:
В оригинале создавался на дискете (это определяется константой)
Эту дискету несут на комп фин. директора
В файле OrdersFin00.mdb есть служебная таблица tblImport которая определяет какие запросы нужно выполнить и в каком порядке
фин директор запускает форму frmExport и данные из файла на дискете запросами описанными в таблице tblImport переносятся (добавляются/обновляются) в таблицы в файле OrdersFin00.mdb
Если файлов с обновлениями несколько. то добавятся все по очереди. | |
| |
| |
| |
|
|
| | osmor
К сожалению, мне не удалось посмотреть служебные таблицы, так как база постоянно ссылается на ошибку скрипта, да и таблиц там не видно видимо из-за настроек запуска, не могли бы вы вывесить ту же версию. но так. что бы в ней были доступны к просмотру таблицы, формы. короче окошечко самой базы данных со списком таблиц тоже было | |
| |
| |
| |
|
|
| | не совсем понял какие там ошибки...положил заново.
ссылка на новый файл в старом сообщении | |
| |
| |
| |
|
|
| | Ой блин. Коровка, удачи разобраться.  | |
| |
| |
| |
|
|
| | там нет ничего сложного 1 основная функция 3-4 вспомогательных (типа проверки наличия диска и наличия файла)
Модуль с диалогом выбора файла можно игнорировать | |
| |
| |
| |
|
|
| | А я как раз делаю такую же бодягу - обмен даными между точками через XML + FTP. Суть та же: через служебные поля в таблицах определять новые/измененные записи (следить за полями не стал - уж тут точно вешалка будет) затем запросами на обновление/добавление по заданым сценариям затаскивать данные в БД. А проблема основная - чтобы не было "перехлеста" в записях. Думается, в какой то мере может спасти, если обмен будет скажем раз в 10 мин (xml получаются порядка нескольких Кб всего) - все меньше вероятности конфликтов. А если не судьба - тогда в таблицу конфликтов и админу на размышление. Что делать с удалениями - тоже вопрос.
ЗЫ:
Сначала запустил репликацию - но база раздулась так быстро и так сильно (архивом приходится таскать почти 1Мб), что пришлось отказываться от такого счастья. Плюс бесконечные конфликты записей, записи пропадают (удаление получило приоритет - чтоб его  ). Репликация через И-нет - напрягает нестабильность подключения.
Зато хоть разбирать xml научился - все не зря время убил  | |
| |
| |
| |
|
|
| | palarm, спасибо)
А можно поменять приоритет, то есть что бы не удаление было в приоритете, а наоборот, что бы из неосновной реплики записи добавлялись в основную, а из основной во время синхронизации ничего не удалялось? | |
| |
| |
