Синхронизация нескольких баз

Для начала опишу то, что хотел сделать и чего добился:
1. Базой пользуются несколько пользователей, т.е. я каждый день высылаю обновленную базу, в которой пользователи работают.
2. Вечером пользователи высылают мне базу. В базе пользователя, путем запросов выделяю записи, созданные на текущую дату, затем экспортирую в exel(конечно же все одной кнопкой)
3. Теперь импортирую в основную базу(которая находиться у меня) из exel, то, что экспортировал.

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

Теперь о проблеме:
База не совсем актуальная, а скорее совсем не актуальная . Дело в том, что таким способом я не вижу внесенные изменения в записях, что, как понимаете не есть гуд. По этой причине данный алгоритм синхронизации баз потерпел фиаско.
В идеале, конечно было бы доработка алгоритма, потому как много придется менять, но если это не возможно, то хотелось бы узнать новый алгоритм, который бы учитывал и новые записи, и изменения в старых.
Заранее благодарен за ответ.

0

Сообщение от ДмитрийСтариков 2. Вечером пользователи высылают мне базу. В базе пользователя, путем запросов выделяю записи, созданные на текущую дату, затем экспортирую в exel(конечно же все одной кнопкой) 3. Теперь импортирую в основную базу(которая находиться у меня) из exel, то, что экспортировал.

Зачем exel? Просто присоединится к таблицам присланных баз поочередно разве нельзя, чтобы найти записи с текущими датами? Заодно можно найти и измененные (удаленные) старые.

Рассматривался вариант с репликами баз данных (у Вас основная). Чем он не устраивает - это же стандартное средство для таких ситуаций?

1

Дмитрий, Репликация не подойдет?

Добавлено через 3 минуты
ltv_1953, опоздал

1

Про "Репликации" в первый раз слышу, буду узнавать , всем огромное спасибо

Добавлено через 40 минут

Сообщение от Андрэич Дмитрий, Репликация не подойдет? Добавлено через 3 минуты ltv_1953, опоздал

На сколько я понимаю, портфельная репликация - это самый простой способ, который мне вполне подойдет, вот только возникает проблема: пытаюсь перенести базу (Access 2007) в портфель, а он мне пишет, что не может работать с базами 2000 - 2003 года и просит преобразовать базу.... Что за ерунда, подскажите плиз

0

Сообщение от ДмитрийСтариков Про "Репликации" в первый раз слышу, буду узнавать , всем огромное спасибо Добавлено через 40 минут На сколько я понимаю, портфельная репликация - это самый простой способ, который мне вполне подойдет, вот только возникает проблема: пытаюсь перенести базу (Access 2007) в портфель, а он мне пишет, что не может работать с базами 2000 - 2003 года и просит преобразовать базу.... Что за ерунда, подскажите плиз

Не сталкивался.
1. Насколько помню, в 2007 Офисе появилось специальное средство в меню папок - синхронизацию, попробуйте (на уровне догадки).
2. Преобразуйте, как хочет

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

0

Сообщение от ДмитрийСтариков ... пытаюсь перенести базу (Access 2007) в портфель...

Вот, что пишет Microsoft

Репликация не поддерживается в файлах формата Office Access 2007. Можно использовать Office Access 2007 для репликации базы данных, созданной в более раннем формате, но нельзя сделать репликацию базы данных, созданной в формате Office Access 2007.

2

В том то и дело, что не пойму чего он хочет. У меня итак не 2000 и не 2003. Синхронизацию не могу найти.... В описании работы с репликами написано так "Сервис → Репликация → Создать реплику" в 2007 нет "Сервис" может где в другом месте.. Подскажите, кто знает?

Добавлено через 4 минуты

Сообщение от Андрэич Не сталкивался. 1. Насколько помню, в 2007 Офисе появилось специальное средство в меню папок - синхронизацию, попробуйте (на уровне догадки). 2. Преобразуйте, как хочет Добавлено через 3 минуты 3. Возможно, не осилили главу до конца: там есть ещё варианты, на мой взгляд, практичнее и проще с точки зрения уже продвинутого уровня...

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

Добавлено через 58 секунд

Сообщение от minob Вот, что пишет Microsoft

А что делать-то?

Добавлено через 12 минут
В инете нешел только такое решение: для пользователей нужно преобразовать свою базу в 2000(2003) и разослать в таком виде, затем мол она с репликами можно решить вопрос. Вот только всплывает другая проблема. В 2003 некоторые важные составляющие перестают работать. Так что это не есть решение проблемы. Какие еще есть варианты???

0

Сообщение от ДмитрийСтариков В том то и дело, что не пойму чего он хочет. У меня итак не 2000 и не 2003. Синхронизацию не могу найти.... В описании работы с репликами написано так "Сервис → Репликация → Создать реплику" в 2007 нет "Сервис" может где в другом месте.. Подскажите, кто знает? Добавлено через 4 минуты Верно, я читаю и пытаюсь сразу сделать, возникают ошибки - пишу, прошу прощения, но время экономиться, на данном примере видно явно Добавлено через 58 секунд А что делать-то? Добавлено через 12 минут В инете нешел только такое решение: для пользователей нужно преобразовать свою базу в 2000(2003) и разослать в таком виде, затем мол она с репликами можно решить вопрос. Вот только всплывает другая проблема. В 2003 некоторые важные составляющие перестают работать. Так что это не есть решение проблемы. Какие еще есть варианты???

Наверно, есть один вариант: пользоваться для разработки А2003; наоборот, не использовать "как-бы усовершенствования" версий выше 2003 (типа полей Вложение, "многозначных полей"...)
(Ещё один случай в копилку "чем лучше А2003"...)

Добавлено через 4 минуты
Плюс к тому, разделять файл на интерфейс (клиент) и таблицы. Файл с таблицами делать в .mdb, который можно синхронизировать

2

Непереносимость продукта большой грех. Очень многие, начав с Jet SQL, продолжили работу в серверных БД. А там поля типа Вложения, многозначные или подстановки в таблицах, если и есть, то в совершенно ином виде и напрямую никак не переносятся. И чтобы не обрекать себя на бесполезную, вообщем-то работу по приведению полей к стандартным типам, лучше сразу пользоваться только такими. Тем более, что работы по преобразованию довольно часто велики по объему переделок, в частности многозначные поля требуют введения новых таблиц и сервисов по их обслуживанию.

0

Дело в том, что уже много(очень)работы проделано в 2007 и делать снова в 2003 то же самое не просто ломы, а очень ломы, на сколько понимаю решения нет, так что буду искать что-то нетривиальное, по крайней мере постараюсь

Добавлено через 44 секунды

Сообщение от mobile Непереносимость продукта большой грех. Очень многие, начав с Jet SQL, продолжили работу в серверных БД. А там поля типа Вложения, многозначные или подстановки в таблицах, если и есть, то в совершенно ином виде и напрямую никак не переносятся. И чтобы не обрекать себя на бесполезную, вообщем-то работу по приведению полей к стандартным типам, лучше сразу пользоваться только такими. Тем более, что работы по преобразованию довольно часто велики по объему переделок, в частности многозначные поля требуют введения новых таблиц и сервисов по их обслуживанию.

Слов красивых много, а где решение проблемы????

0

mobile,
читал, что в "новых" версиях SQL введен такой многозначный тип. Но не уверен, что будет работать, например, с MS SQL...
Но не уверен, так как не пробовал...
???
(ради ликбеза :-) )

0

Сообщение от ДмитрийСтариков Дело в том, что уже много(очень)работы проделано в 2007 и делать снова в 2003 то же самое не просто ломы, а очень ломы, на сколько понимаю решения нет, так что буду искать что-то нетривиальное, по крайней мере постараюсь Добавлено через 44 секунды Слов красивых много, а где решение проблемы????

Моя реплика относилась к Вашему пассажу

Сообщение от ДмитрийСтариков Вот только всплывает другая проблема. В 2003 некоторые важные составляющие перестают работать. Так что это не есть решение проблемы. Какие еще есть варианты???

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

Добавлено через 3 минуты

Сообщение от Андрэич mobile, читал, что в "новых" версиях SQL введен такой многозначный тип. Но не уверен, что будет работать, например, с MS SQL... Но не уверен, так как не пробовал... ??? (ради ликбеза :-) )

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

1

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

Дык. А как они могли ещё это сделать в рамках реляционной модели?
(Имхо, скрытые таблицы индексов ведь прижились без критики?)

0

Сообщение от mobile Моя реплика относилась к Вашему пассажу Для студентческих работ проходит многое, но у Вас, судя по всему, промышленная разработка. А к ним иные требования. И отвечать, советовать что-либо, пока не решены основные вопросы, я не предполагаю.

Да, это промышленная задача, в рамках самостоятельной разработки не программиста, а пользователя, так, что можно уровнять со студенческой...
По методу ТРИЗ вышел на разбиение задачи на несколько подзадач, т.е.: если раньше была одна таблица "Звонки", в которой были поля "Цель_звонка" и "Результат_звонка", при внесении изменений в "Результат_звонка", изменения не отслеживались, то при новом раскладе можно разделить "Звонки" на две таблицы "Цель_звонка" и "Результат_звонка", в каждой из которых будет поле "Дата_создания" и отслеживать так... Но что-то мне не очень нравиться такой подход, может кто-нибудь подскажет более правильный алгоритм????

0

Сообщение от mobile Моя реплика относилась к Вашему пассажу Для студентческих работ проходит многое, но у Вас, судя по всему, промышленная разработка. А к ним иные требования. И отвечать, советовать что-либо, пока не решены основные вопросы, я не предполагаю. Добавлено через 3 минуты Да, я тоже слышал. Но пока не работал с ним. В оракле такое есть давно, но организация совершенно иная, чем решение в Access, где это сделано через задний проход - есть скрытая системная таблица, задающая отношение "многие-ко многим" и с ее помощью реализуются многозначные поля.

[QUOTE=ДмитрийСтариков;3791315]

Сообщение от mobile Моя реплика относилась к Вашему пассажу Для студентческих работ проходит многое, но у Вас, судя по всему, промышленная разработка. А к ним иные требования. И отвечать, советовать что-либо, пока не решены основные вопросы, я не предполагаю. Да, это промышленная задача, в рамках самостоятельной разработки не программиста, а пользователя, так, что можно уровнять со студенческой... По методу ТРИЗ вышел на разбиение задачи на несколько подзадач, т.е.: если раньше была одна таблица "Звонки", в которой были поля "Цель_звонка" и "Результат_звонка", при внесении изменений в "Результат_звонка", изменения не отслеживались, то при новом раскладе можно разделить "Звонки" на две таблицы "Цель_звонка" и "Результат_звонка", в каждой из которых будет поле "Дата_создания" и отслеживать так... Но что-то мне не очень нравиться такой подход, может кто-нибудь подскажет более правильный алгоритм????

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

0

1. Выбрав 2007 Вы сами лишили себя стандартного средства - реплик баз данных.
2. Существует доморощенный способ - каждая обрабатываемая таблица из основной базы сравнивается с соответствующей таблицей из пользовательской базы с использованием трех запросов, определяющих новые записи, удаленные записи, измененные записи. По результатам этих запросов принимается решение о внесении изменений в основную базу. Для двух баз Access нужды применять его не было, но для Access и выгрузки из другой базы он вполне работал.
3. Пользователи, во избежании коллизий (внесения разными пользователями изменений в одну и туже запись), получают для работы не всю базу, а только ту ее часть, которая их касается (если пользователи торговые агенты, например, то они получают только данные, касающиеся их клиентов).

1

Сообщение от ltv_1953 1. Выбрав 2007 Вы сами лишили себя стандартного средства - реплик баз данных. 2. Существует доморощенный способ - каждая обрабатываемая таблица из основной базы сравнивается с соответствующей таблицей из пользовательской базы с использованием трех запросов, определяющих новые записи, удаленные записи, измененные записи. По результатам этих запросов принимается решение о внесении изменений в основную базу. Для двух баз Access нужды применять его не было, но для Access и выгрузки из другой базы он вполне работал. 3. Пользователи, во избежании коллизий (внесения разными пользователями изменений в одну и туже запись), получают для работы не всю базу, а только ту ее часть, которая их касается (если пользователи торговые агенты, например, то они получают только данные, касающиеся их клиентов).

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

0

Есть Таблица с ключевым полем Запись_Код, который пользователи изменять не могут (тип счетчик). Таблица (в основной базе) сравнивается с ее "копией" Таблица1 в копии пользователя.
Новые определяются запросом
Удаленные запросом
Измененные запросомусловие WHERE, которое нужно добавить в этом запросе, должно проверять, есть ли хотя бы одно несовпадение в полях Таблицы.
И так для каждой таблицы, которую нужно синхронизировать.

1