Задача: находясь рядом с удаленной базой сделать несколько вставок в одну из ее таблиц, участвующую в репликации, таким образом, чтобы эта вставка не передалась в консолидированную. При этом не допускается останка репликации. Как это лучше сделать?
Смотрю в сторону PASSTHROUGH ONLY FOR user_id, но смущает следующее:

BOL
If the ONLY keyword is used to start passthrough mode, the statements are not executed at the server; they are sent to recipients only.


Т.е. он предназначен для отправки изменения в другую базу без применения к локальной? А мне нужно наоборот.

Рыжий Кот пишет:
> LOAD TABLE не пойдет?

страшновато. надо проверять.
Posted via ActualForum NNTP Server 1.2

Рыжий Кот пишет:
> off: для чего это все понадобилось? репликация слегка разъехалась?

Именно. Воткнул новую таблицу в подписку (пустую). А точнее даже две -
шапка и строчки документа типа накладной. Но в удаленной базе забыл
убрать с нее FK на таблицу, которая хоть и присутствует, но не
реплицируется и вообще пустая. Ладно, проблему решил с консолидированной
базы, удалив и вставив по новой введенные данные.
Posted via ActualForum NNTP Server 1.2

> Именно. Воткнул новую таблицу в подписку (пустую).

Имелась в виду пустая таблица, а подписка была очень даже не пустая.

Кстати, еще вопрос на засыпку. Если отправить изменения через
PASSTHROUGH ONLY FOR user_id, то сработают ли в получившей базе
триггера, обернутые в IF CURRENT REMOTE USER IS NULL ... END IF?
Posted via ActualForum NNTP Server 1.2

Рыжий Кот пишет:
> поскольку все изменения все равно применяются от имени remote user-а
> (который remote dba).
> Хотя если в dbremote прописать uid равным dba, то может и да... не знаю :)

Кстати, вот еще вопрос по ходу (надоело самому отвечать, я тоже не все
знаю ;)

Я в строке подключения dbremote везде dba использую. Чем это плохо? Оно
и в примерах в BOL везде так. В качестве паблишеров и удаленных юзеров,
естественно, используются отдельные пользователи.
Posted via ActualForum NNTP Server 1.2

White Owl пишет:

>> Я в строке подключения dbremote везде dba использую. Чем это плохо? Оно
>> и в примерах в BOL везде так.

> Плохо тем, что юзер может залезть в скрипт/ярлык/чего-там еще запуска
> dbremote и подсмотреть пароль DBA :)

И все? Больше ничем? На хитрых юзеров есть нормальные сисадмины. А если
фирма без сисадмина и юзеры имеют доступ ко всем скриптам, то dbfhide
заметно усложнит задачу получения пароля. Хоть и не сильная
криптография, но что-то я не слышал про распространенные утилиты
расшифровки.
Posted via ActualForum NNTP Server 1.2

PaulJB пишет:
> Вобще-то с помощью PASSTHROUGH ONLY FOR user_id данные не передашь. Она
> предназначена только для внесения изменения в структуру базы, а не в
> данные. Система тебя обругает если ты между PASSTHROUGH ONLY FOR user_id
> и PASSTHROUGH STOP поставишь комманду типа INSERT,UPDATE,DELETE.

С чего бы это вдруг? В PASSTHROUGH режиме просто без изменений
передаются ВСЕ SQL запросы. По крайней мере я таким образом без проблем
передавал CALL ProcedureName(....)

> А на счет юзера для агента - создай в базе полностью бесправного юзера,
> установи ему аттрибут RemoteDBA и пусть после этого хитрые юзера и
> админы подсматривают его пароль. :)

Да у меня то проблемы подсматривания паролей нет. Конфигурационные файлы
шифруются как средствами ASA, так и ОС. Но за идею спасибо, можеть
пригодиться. Как-нибудь на досуге проверю.
Posted via ActualForum NNTP Server 1.2

PaulJB пишет:

> Про юзера: я забыл указать, что у него надо оставить только RemoteDBA, а
> DBA и Resource надо убрать, ибо сюрприз не получится. :)

Прочитал про Remote DBA. Но это не сильно поможет. В файле конфига для
dbremote кроме логина и пароля есть еще ключик -ek с ключом шифрования
базы. А это почувствительнее будет в плане информационной безопасности.
Posted via ActualForum NNTP Server 1.2