Реализация репликации данных

[sergeypp]

Цитата:

Сообщение от George Nordic

3йка или 4ка? В 4ке не будет проблем с RecId.

3-ка sp3

Цитата:

Сообщение от George Nordic

Можно просто перегонять данные в промежуточную таблицу и закачивать в основную (или через журналы). Тогда не будет проблем ни с RecId, ни с номерными сериями. Вопрос, насколько точная нужна репликация. Надеюсь, не с точностью до номерной серии и RecId.

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

Цитата:

Сообщение от Alexius

1. Нет проблем, были в начале, когда в Аксапте подписчике были права на изменения и добавления в виртуальных таблицах.
2. Да, надо переинициализировать репликацию после синхронизации.
3. Не вижу проблем
4. Нет проблем при односторонней репликации
5. Да, надо переинициализировать репликацию после синхронизации.
6. ???
7. При однонаправленной репликации, нет проблем.
8. При использовании репликации транзакций MSSQL на таблицах не создаются триггеры.

1. А можно по-подробнее про виртуальные таблицы?
3. Пока база в репликации, восстановить себя она не даст, нужно будет отвязывать всех подписчиков
7. Сомнительно.. возможны частные случаи
8. Еще как создаются. создаются тригеры на добавление, удаление и изменение , которые пишут данные в журнал

Просто возможно существуют другие варианты , например без использования скулевой репликации как таковой вообще.
Данные можно кидать и DTS? правда я не знаю насколько DTS требователен к каналу??.
Интересный вариант и с журналом.. сейчас покопаю туда.
Просто еще вопрос стоит под следующим углом.. Если механизм передачи данных инкапсулировать от пользователей, то последние начинают придумывать ввсякие небылицы о том что данные не пришли или пришли криво, оправдывая тем самым свои ошибки. А если что то действительно начнет работать наперекосяк, можно смело тащить раскладушку на работу. Даже в перепроверенной системе могут вылезти непредвиденные ошибки.
Может дейсвительно есть резон отказаться от схем "теневой" передачи, а выкладывать данные на фтп как вариант и административно принудить пользователей самим обновлять систему. Тогда странных предположений от подльзователей будет намного меньше. Залили файл - данные обновились, Не залили - не обновились, но опять таки разовая заливка может оказаться ресурсоемкой, тогда будут возникать другие жалобы, что они не успевают и не могут работать.. Ньюансов много.. как сделать лучше, пока непонятно