Каким образом можно во вторую, идентичную реплицируемой, таблицу записать измененное значение (флаг) не зависимо от того какой там был раньше.
надеялся можно в фильтре прописать
Select col1,col2, 1 FROM <<TABLE>> WHERE ...
фиг...
Как то можно через DTS...
а как ...

Для GreenSunrise:
Две таблицы в разных базах.
Из первой во вторую переносятся данные с флагом Col3=1
Из второй в первую та же картина.
чтобы не летала запись туда сюда нужно сохранять в подписчика Col3=0. Как реализовать? :)

Для AAron:
SELECT <published_columns> FROM <<TABLE>> WHERE Col3=1
Или они разных типов бывают?
Если нет- какая теперь разница, (для меня)
Есть еше в свойстве Table Article Properties-> commands - (ну команды, процедуры)
Если туда загнать процедуру которая будет изменять значение поля Col3 на 0.

Уважаемый Олег Яговкин, думаю было бы нахальством просить сделать за меня работу :)
Плохо объяснил, попробую еще раз.
Есть два сервера (на каждом публикуются данные). С каждого данные отсылаются Push подпиской с использованием фильтра Col3=1 (т.е. передавать только измененные записи, у которых Col3=1, остальные изменения не учитывать).
Как я понимаю, если было сделано обновление (независимо руками или репликацией) изменения публикуются и отправляются на другой сервер, где делают обновление.

“то записи с любым флагом "летать туда сюда" не будут т.к. есть поле rowguid” – я вот и не пойму почему не будет обновления. Вроде изменения есть. Rowguid – сравнивается с подписчиком и если совпадает – не публикуется – так что ли?

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

>>Или Вы хотите, чтобы поле col3 вообще не участвовало в репликации? И было различным на >>паблишере и подписчике? Тогда стоит задуматься о публикации не таблиц, а вьюх.
Надеюсь, будет понятно из нижеизложенного. :)

>>Если же вам необходимо например из 1000 записей в табл. выделить напр. 100 (с Col3=1) (для >>ваших каких то целей)то при работе агентов репликации, изменения производимые в этих >>записях (т.к. они участвуют в фильтре) и будут передаваться между двумя таблицами.

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

И то и другое.
Дело в том, что данные должны передаваться не при всех изменениях, т.е. если, например, изменения в Col1- обновлять (причем изменение может таковым считаться при изменении на конкретные значения), если в Col2 –нет – можно еще сказать о зависимости от того, например, какой пользователь изменяет (это я просто так сказал :)).

>>. Т.е. если есть изменения для записи с данным rowguid, то она соответствующим образом >>изменяется как на публикующем, так и на подписчике.

Уточню :), она - rowguid (в том числе)? Если да, то, что делать, если строка изменилась, но не прошла по фильтру, в следующий раз при изменении удовлетворяющем фильтрации rowguid на подписчике не найдется, и запись будет INSERTнута – а ключ вставляемой записи в таблице уже есть.

И на счет “туда сюда” проверял я, агенты при изменении любой записи начинают показывать, что «выполняется одна транзакция 2 команды». Завершения этого я не дождался (оставлял на ночь :)). Или оно так и быть надо?

Спасибо за советы.