синхронизация баз данных-MS Access

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

вам нужно будет рассмотреть первичные ключи. Возможно, лучше всего включить имя пользователя или ноутбука в ключ, чтобы убедиться, что записи связаны правильно.

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

возможно использовать двигатель репликация встроена в Access, но я предупреждаю, она довольно шелушащаяся.

Jet репликация не flakey. Вполне надежна правильно, как и любой другой сложный инструмент. Верно, что некоторые вещи, которые не вызывают проблем в нереплицированной базе данных, могут привести к проблемам при репликации, но это понятно из-за характера репликации любой компонент database engine влечет за собой.

Это также испортит ваш ПК на все столы вы делаете это, потому что он выбирает случайные целые числа со знаком, чтобы попробовать и избегайте ключевых столкновений, чтобы вы могли в итоге -1243482392912 как ваш следующий PK на данной записи. Это PITA для ввода, если вы делаете вид поиска (как клиент ID, номер заказа и т. д.)

суррогатный автономер PKs никогда не должен подвергаться воздействию пользователей в первую очередь. Это бессмысленные числа, используемые для объединения записей за кулисами, и если вы предоставляете их пользователям, это ошибка в дизайне приложения.

Если вам нужны порядковые номера, вам придется свернуть свой собственный и решить этот вопрос о том, как предотвратить столкновения между вашими репликами. Но это проблема для репликации в любой компонент database engine. SQL Server предлагает возможность выделения блоков порядковых номеров для отдельных реплик на уровне ядра СУБД, и это действительно хорошая функция, но это происходит за счет увеличения административных издержек от обслуживания нескольких экземпляров SQL Server (со всеми вытекающими проблемами безопасности и производительности). В Jet Replication вам придется сделать это в коде, но это вряд ли сложная проблема.

другой альтернативой было бы использование составного ПК, где один столбец указывает исходную реплику.

но это не какой-то недостаток в реализации репликации Jet-это проблема для любого сценария репликации с необходимостью значимых порядковых номеров.

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

Это явно неправда. При установке Jet synchronizer можно запланировать синхронизацию (прямую, косвенную или интернет-синхронизацию). Даже без него вы можете запланировать периодический запуск VBScript и синхронизацию. Это всего лишь два метода выполнения автоматической синхронизации струи без необходимости открывать приложение Access.

цитата из документации MS:

используйте двигатель и Объекты Репликации

JRO действительно не лучший способ управления репликацией Jet. Во-первых, в нем есть только одна функция, которой не хватает самому DAO, т. е. возможность инициировать косвенную синхронизацию в коде. Но если вы собираетесь добавить зависимость к своему приложению (JRO требует ссылки или может использоваться через позднюю привязку), вы можете также добавить зависимость от действительно полезной библиотеки для управления репликацией Jet, и это синхронизатор TSI, созданный Майкл Каплан, когда-то крупнейший в мире специалист по реактивной репликации (который с тех пор перешел на интернационализацию в качестве своей области концентрации). Это дает вам полный программный контроль почти всех функций репликации, которые предоставляет Jet, включая планирование синхронизации, инициирование всех видов синхронизации и столь необходимую команду MoveReplica (единственный законный способ перемещения или переименования реплики без нарушения репликации).

JRO является одним из уродливых пасынков Microsoft прервала кампанию ADO-Everywhere. Его цель состоит в том, чтобы обеспечить функциональность Jet для дополнения того, что поддерживается в самом ADO. Если вы не используете ADO (и вы не должны быть в приложении Access с jet back end), то вы действительно не хотите использовать JRO. Как я уже сказал выше, он добавляет только одну функцию, которая еще не доступна в DAO (т. е. инициирует косвенную синхронизацию). Я не могу не думать, что Microsoft была злой, создавая автономную библиотеку для Jet-specific функциональность, а затем целенаправленно опуская все невероятно полезные функции, которые они могли бы поддерживать, если бы захотели.

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

поскольку у вас есть инфраструктура только для добавления, сделайте то, что рекомендовал @Remou, и настройте что-то, чтобы вручную отправить новые записи туда, куда им нужно идти. И он прав, что тебе все еще нужно разобраться с проблемой ПК., как если бы вы использовали репликации Jet. Это связано с необходимостью добавления новых записей в нескольких местах и является общим для всех приложений репликации/синхронизации.

но одно предостережение: если сценарий add-only изменится в будущем, вам придется начинать с нуля или писать много волосатого кода для управления удалениями и обновлениями (это непросто-поверьте мне, я это сделал!). Одно из преимуществ использования репликации Jet (даже хотя это наиболее ценно для двусторонней синхронизации, т. е. редактирования в нескольких местах), это то, что он будет обрабатывать сценарий только для добавления без каких-либо проблем, а затем легко обрабатывать полную репликацию слиянием, если это станет требованием в будущем.

наконец, хорошим местом для начала репликации Jet является Реактивная Репликация Wiki. Ресурсы, лучшие практики и вещи, чтобы не верить страницам, вероятно, лучшие места для начала.

вы должны прочитать в открыть база данных репликация, так как есть некоторая информация.

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

используйте объекты Jet и репликации (JRO), если требуется программный контроль над обменом данные и сведения о конструкции среди членов набора реплик в базах данных Microsoft Access (.МБР только файлы). Например, с помощью JRO можно написать процедуру, которая автоматически синхронизирует реплику пользователя с остальной частью набора при открытии базы данных. Чтобы реплицировать базу данных программно, она должна быть закрыта.

если база данных была создана с помощью Microsoft Access 97 или более ранней версии, необходимо использовать объекты доступа к данным (DAO) для программной репликации и синхронизировать.

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

вы можете использовать следующие методы и свойства для создания и обслуживания реплицированной базы данных:

• MakeReplica метод
• Synchronize метод
• ConflictTable свойства
• DesignMasterID свойства
• KeepLocal свойства
• Replicable свойства
• ReplicaID свойства
• ReplicationConflictFunction свойства

Microsoft Jet предоставляет эти дополнительные методы и свойства для создание и обслуживание частичных реплик (реплик, содержащих подмножество записей в полной реплике):

• ReplicaFilter свойства
• PartialReplica свойства
• PopulatePartial метод

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

Я использовал репликацию в a00 в течение многих лет, пока не был вынужден перейти на a07 (когда он ушел). Самой проблемной проблемой, с которой мы столкнулись на уровне предприятия, было управление конфликты. Если не удается своевременно, или их слишком много, пользователи расстраиваются, и данные становятся ненадежными.

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

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

у пользователя была отдельная кнопка, чтобы нажать / вытащить каналы из назначенного FTP-файла, который будет обновляться из устаревших систем.

этот процесс работал довольно хорошо, так как у нас было 30 из этих "узлов", работающих по всей стране, управляя своими данными и обновление до FTP-серверов.

Если вы серьезно рассматриваете этот путь, дайте мне знать, и я могу отправить вам мою документацию.

вы можете написать свое собственное программное обеспечение синхронизации, которое подключается к ноутбуку, выбирает diff из его db и вставляет его в мастер. Это зависит от вашей схемы данных, насколько простой будет эта операция. (если у вас много таблиц с FKs... вам нужно будет сделать это умно). Я думаю, что это будет наиболее эффективным, если вы напишите его сами.

автоматизация такого поведения называется репликацией, и Accesss поддерживает что, по-видимому, но я никогда не видел его выполненный.

Как я думаю, большую часть времени ноутбук не подключен к основной БД, это не очень хорошая идея (для репликации данных).

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

FWIW:

1. автономерами. Я согласен с Дэвидом - они никогда не должны быть открытыми. Чтобы устранить это искушение, я использую случайный autonumber.
2. репликация. Я широко использовал это несколько лет назад, с запланированными синхронизациями и использованием GUID в качестве ПК. Я неоднократно обнаруживал, что любые сбои в сети повреждали реплики, в результате чего мне приходилось спасать данные и повторно выпускать реплики. Больно!