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

Question

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

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

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

Какие инструменты позволят мне сделать это легко? Какие факторы будут влиять на решение о лучшем инструменте или решении?

Answer 1

Можно использовать репликацию Jet, встроенную в Access, но я предупрежу вас, она довольно нестабильная. Он также испортит ваш ПК в любых таблицах, в которых вы это делаете, потому что он выбирает случайные целые числа со знаком, чтобы попытаться избежать коллизий ключей, поэтому вы можете в конечном итоге использовать -1243482392912 в качестве следующего ПК в данной записи. Это PITA для ввода, если вы выполняете какой-либо поиск по нему (например, идентификатор клиента, номер заказа и т. Д.). Вы не можете автоматизировать синхронизацию доступа (возможно, вы можете подделать что-то подобное с помощью VBA. Но все же , будет выполняться только при открытой базе данных).

Я бы порекомендовал использовать SQL Server 2005/2008 в своей «центральной» базе данных и использовать выпуски SQL Server Express Edition в качестве серверной части в «удаленных» базах данных, а затем использовать связанные таблицы в Access для подключитесь к этим базам данных SSEE и выполните репликацию для их синхронизации. Настройте либо репликацию слиянием, либо репликацию моментальных снимков с вашей "центральной" базой данных в качестве издателя и ваших баз данных SSEE в качестве подписчиков. В отличие от репликации Access Jet, вы можете контролировать нумерацию PK, но для вас это не будет проблемой, поскольку ваши подписчики не будут продвигать изменения.

Помимо масштабируемости, которую принесет SQL-сервер, вы также можете автоматизировать это с помощью диспетчера синхронизации Windows (если у вас есть синхронизированные папки, это раздражающее маленькое окно, которое всплывает и синхронизирует их при входе / выходе из системы), и установите его таким образом, чтобы он синхронизировался с заданным интервалом, при запуске, завершении работы или в определенное время суток, и / или когда компьютер не используется, или синхронизируется только по требованию. Даже если Access не запускается в течение месяца, его набор данных может обновляться каждый раз, когда ваши пользователи подключаются к сети. Очень классные вещи.

Answer 2

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

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

Answer 3

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

Возможно использовать Jet Репликация встроена в Access, но я предупреждает вас, это довольно хлопотно.

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

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

Суррогатные Autonumber PK никогда не должны быть открыты для пользователей. Это бессмысленные числа, используемые для соединения записей за кулисами, и если вы предоставляете их пользователям, это ОШИБКА В ВАШЕМ ДИЗАЙНЕ ПРИЛОЖЕНИЯ.

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

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

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

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

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

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

Использовать объекты Jet и Replication

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

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

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

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

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

И наконец, хорошее место для начала с Jet Replication - Jet Replication Wiki . Страницы «Ресурсы, лучшие практики и вещи, которым нельзя верить», вероятно, являются лучшими местами для начала.

Answer 4

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

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

Используйте объекты Jet и Replication Object (JRO), если вам требуется программный контроль над обменом данными и проектной информацией между членами набора реплик в базах данных Microsoft Access (только файлы .mdb). Например, вы можете использовать JRO для написания процедуры, которая автоматически синхронизирует реплику пользователя с остальной частью набора, когда пользователь открывает базу данных. Для программной репликации базы данных ее необходимо закрыть.

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

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

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

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

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

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

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

Answer 5

Я использовал репликацию в a00 в течение многих лет, пока не был вынужден обновиться до a07 (когда он исчез). Наиболее проблемной проблемой, с которой мы столкнулись на уровне предприятия, было управление КОНФЛИКТАМИ . Если своевременно не управлять или их слишком много, пользователи разочаровываются и данные становятся ненадежными.

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

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

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

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

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

Answer 6

FWIW:

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

Answer 7

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

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

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

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