синхронизация базы данных - Доступ MS

Question

синхронизация базы данных - Доступ MS

Это - самый простой способ получить время Unix:

use Time::Local;
timelocal($second,$minute,$hour,$day,$month-1,$year);

Примечание обратный порядок аргументов и в том январе месяц 0. Для значительно большего количества опций посмотрите модуль DateTime от CPAN.

Что касается парсинга, посмотрите Дата:: Синтаксический анализ модуль от CPAN. Если действительно необходимо стать необычными с парсингом даты, Дата:: Manip может быть полезным, хотя его собственная документация предупреждает Вас далеко от него, так как он несет много багажа (он знает вещи как общие бизнес-праздники, например), и другие решения намного быстрее.

, Если Вы, оказывается, знаете что-то о формате даты/времен, что Вы будете анализировать тогда простое регулярное выражение, может быть достаточным, но Вы - вероятно, более обеспеченное использование соответствующего модуля CPAN. Например, если Вы знаете, что даты всегда будут в порядке YMDHMS, использовать модуль CPAN DateTime:: Формат:: ISO8601.

Для моей собственной ссылки, если ничто иное, ниже не является функцией, я использую для приложения, где я знаю, что даты всегда будут в порядке YMDHMS со всеми или частью "на службе ее величества вооруженных сил Великобритании" дополнительной части. Это принимает любые разделители (например, "2009-02-15" или "2009.02.15"). Это возвращает соответствующее время Unix (секунды с тех пор 01.01.1970 0:00:00 GMT) или-1, если это не могло бы проанализировать его (что означает Вас лучше быть уверенным, что Вы никогда не должны будете законно анализировать дату 31.12.1969 23:59:59). Это также предполагает двухразрядные годы XX, до "69" относятся к "20XX", иначе "19XX" (например, "50-02-15" означает 15.02.2050, но "75-02-15" означает 15.02.1975).

use Time::Local;

sub parsedate { 
  my($s) = @_;
  my($year, $month, $day, $hour, $minute, $second);

  if($s =~ m{^\s*(\d{1,4})\W*0*(\d{1,2})\W*0*(\d{1,2})\W*0*
                 (\d{0,2})\W*0*(\d{0,2})\W*0*(\d{0,2})}x) {
    $year = $1;  $month = $2;   $day = $3;
    $hour = $4;  $minute = $5;  $second = $6;
    $hour |= 0;  $minute |= 0;  $second |= 0;  # defaults.
    $year = ($year<100 ? ($year<70 ? 2000+$year : 1900+$year) : $year);
    return timelocal($second,$minute,$hour,$day,$month-1,$year);  
  }
  return -1;
}

8

ms-access data-synchronization

задан Jonas 19 December 2011 в 03:32

6 ответов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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