Здравствуйте!

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

Задача:
Проводить синхронизацию по расписанию и/или по событиям, то-есть через триггеры или глобальным отслеживанием изменений.

Собственно вопросы:
1) Планируете ли вы, реализовать поддержку синхронизации по расписанию в будущих версиях?
2) Имеется ли возможность проводить синхронизацию через командную строку, пользуясь батником в планировщике винды? На msAccess я такой фишки тоже не нашел.
3) Есть ли команда синхронизации, поддерживаемая триггером? На кнопки надстройку Synchronize нашел, только не ясно что в "параметрах" указывать, иначе без них, открывает диалоговое окно синхронизации, а во всех случаях, нужна автоматизация процесса.
4) Каким сторонним софтом можно автоматически синхронизировать базы данных Access и будут ли они потом исправно работать с вашей программой?

Здравствуйте.
Предже всего к вам вопрос, почему вы решили, что так делать можно? Как работает синхронизатор Google, никому не известно.
Тут бинарная синхроинзация, в то время как синхронизатор Access (или MS SQL) делает синхроинзацию "по записям" и "по полям".
Для синхронизации предусмотрена специальная процедура, которую должен выполнять администратор.
Я бы вам рекомендовал сначала позадавать вопросы на форуме sql точка ru, в соответствующем разделе.

>клиенты работают со своими репликами и должны периодически синхронизироваться с основной
А, если пара филиалов решат синхронизироваться одновременно... вероятность краха и потери данных будет высокая.

_________________
2B OR NOT 2B = TRUE

Гугл синхронизирует полной заменой файла по последним изменениям на одной из машин. Да и ради Бога, пусть заменяет, реплики то отдельно лежат, у каждого своя. С основной репликой ни кто и так работать не должен, только синхронизироваться, она по сути как буфер обмена изменений. Если одновременно синхронизовались две-три машины, то и пусть, гугл заменит на последюю по времени, а утраченные изменения "опоздавших" машин, перенесутся из реплики при следующей синхронизации, когда основная реплика и интернет, будут не заняты.
По времени совпадать синхронизации будут редко, при использовании триггеров разве что, но по расписанию вообще проблем нет, достаточно расставить определенное смещение времени синхронизации для каждого филиала.
У Вас есть ответы на мои вопросы?

>Гугл синхронизирует полной заменой файла по последним изменениям на одной из машин
Интересное получается "кино".
Филиал №1 изменил у "Клиента" (запись ID=1) поле "Адрес", а филиал №2 изменил чуть позже у того же клиента (ID=1) поле "Телефон".
Тогда при синхронизации изменения, сделанные филиалом №1 получается, что потеряются. Не так ли?
Вы проводитли тестирование?

_________________
2B OR NOT 2B = TRUE

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

Реализуйте возможность синхронизации командной строкой и тогда правильным батником, можно будет реализовать поочередную синхронизацию с файлом-флагом эстафеты, на диске гугла, определяющим, кто следующий и когда в праве синхронизироваться.
Записи полей можно изменять другим принципом, в репликациях ID -- это случайные огромные числа, если Вы забыли. Изменения в поле можно проводить подменой всей записи с последующим объединением по служебному коду, флагам или как ещё фантазия программиста позволит, добавляя стопитцот служебных полей на любой вкус. Я все это сделаю, не вопрос, даже спортивный интерес, но мне нужна возможность автоматической синхронизации.

>проблемы системы репликаций в целом
Описанная мной вполне конкретная ситуация успешно решена и продумана и не является вообще проблемой при использовании нормального механизма репликации и правильной технологии синхронизации. Изменения, сделанные обоими филиалами попадут в главную реплику.
Проблемой данная ситуация становится только при вашей схеме.
А потом вы начнете грешить на программу, что у вас данные пропадают? Рекомендую вам посмотреть наше обучающее видео "Репликация баз данных" и использовать данную технологию "по инструкции" вместе Microsoft SQL Server, тогда все будет ОК. Так делают многие наши уважемые клиенты, имеющие точно такие же причины (слабый интернет в отдельных филиалах).

_________________
2B OR NOT 2B = TRUE

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

Вы можете по триггеру вызвать команду Synchronize - откроется форма, затем команду PressButton "ОК" - нажмется кнопка ОК.
И таким образом синхронизация по расписанию возможна.
Все параметры эта форма восстанавливает при открытии.

Проблема будет с таблицей tblSettings, в результате вы можете получить очень большие "странности".

_________________
2B OR NOT 2B = TRUE

Вот, уже ближе к телу, спасибо

1) Пробовал вставить команду в триггер, но без результата. Куда именно вставлять? Команду запуска кнопки окей, там же с новой строчки или следующим триггером? Что должно быть в поле "тип команды"?
2) Для авто-запуска триггера, есть возможность выставлять раз в час, а можно ли более гибко реализовать расписание времени? К примеру час + 10 мин, час + 20 мин, для след. филиала...

1) Тип команды: VBScript
Триггер:
Synchronize
PressButton "ОК"

_________________
2B OR NOT 2B = TRUE

Большое спасибо!

Ещё вопрос касательно tblSettings, какие именно траблы могут быть с этой таблицей? Вы в ней организовали служебные данные механизма синхронизации или туда вносятся служебные данные при добавлении/изменении записей рабочих таблиц? История изменений участвует как-то в синхронизации? А должна я считаю, очень удобно Синхронизация вашей программы отличается чем-то от механизмов синхронизации чистого Access?

Ещё вопрос по времени срабатывания триггера: Раз в час имеется ввиду относительно чего? После запуска программы или привязка к системным часам?

Собственно как реализовать смещение времени, уже придумал. Можно задать запуск триггера раз в минуту, где микрокод будет проверять системное время и при соответствии с заданными параметрами, запускать синхронизацию. Оператор If бла-бла-бла. Помогите правильно расписать.

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

Имеющимися средствами можно как-то так:
Из под Access создаем таблицы tblHistory<FilialName> c номером или именем филиалов, также tblHistoryOld<FilialName> . Создаем такие файлы за каждый имеющийся филиал. Access нужен чтоб их изменения не велись в истории, ну или вы подскажете где какой флаг поправить в tblSettings для этого, или как временно отключать ведение истории.
Шаги синхронизации:
1) Копируем из всех tblHistory<FilialName> в tblHistoryOld<FilialName> недостающие записи.
2) Так же копируем новые записи из tblUpdatesHistory в tblHistory<FilialName> данного филиала, определив к какому филиалу относится реплика через служебные пометки.
3) Синхронизируем все tblHistory<FilialName> и только их, выбрав такую возможность изначально при создании реплик. Что позволит синхронизатору безошибочно лишь добавить недостающие новые записи индивидуальных таблиц истории с их уникальным ID
4) Создаем записи/изменения в рабочих таблицах путем выявления уникальных записей из таблиц старой и новой истории всех филиалов. Что исключит перезапись всех записей в рабочих таблицах, записывая лишь недостающие.
Как-то так в общем

Кнопка не нажимается.

С бинарной синхронизацией у вас ничего не получится в плане организации многофилиальной работы. Проведите тестирование, сами убедитесь. Функционал репликации реализуется в программе посредством технологии Microsoft Jet Replicatrion Objects в случае Access, а при MS SQL Server - его объекты. Т.е. в любом случае это не наша разработка, мы только предоставляем в программе интерфейс для выполнения синхронизации и создания реплик.

_________________
2B OR NOT 2B = TRUE

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

Импорт-экспорт: данные не синхронизируются второй раз, если проведены с родительской репликой, с другими не проверял собственно. Но есть подозрение. На этот случай строим (не сегодня придуманную) схему сетевых протоколов -- звезду или кольцо из ряда дочерних реплик. Не стал проверять, так как нашел более эффективный метод:
Отдельно реплика для экспорта и для импорта, причем можно кольцом или так же звездой. В случае звезды, строится пара файлов реплик синхронизации, для каждой пары филиалов, либо цепью. Эту схему проверил в нескольких вариациях, с многократным откатом реплики-буфера, прекрасно РАБОТАЕТ, хоть с десятого раза инфу передавай. В финальной версии можно малость упростить, уменьшив тем самым число буферных реплик ну и самих операций по синхронизации...

Знаете, если я ещё пол часика пофантазирую, то ещё десять методов придумаю. Может приступим к конструктивному диалогу и Вы мне поможете в тех вопросах, где я нуждаюсь в вашей помощи?...
В частности:
1) По какой причине не работает PressButton? Эта функция у вас точно прописана? В диалоговом окне там возможно не "ОК", может проблема в имени кнопки?
2) Возможно ли таким самым образом, переключаться в диалоговом окне между импортом и экспортом? Как и репликами?
3) На будущее, есть ли возможность объединить в одном триггере SQL и VB?

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