Привет. У репликации ASA есть 2 вида фильтрации информации по узлам:
1. По условию (WHERE) - это полезно, когда информация должна реплицироваться только при определенном состоянии. Например в таблице есть поле-флаг "Обработано" и в репликацию должны попадать только записи с выставленным флагом. Тогда мы указываем WHERE Обработано=1 и получаем нужную функциональность.
2. По подписчику (SUBSCRIBE) - это полезно, когда каждая точка в репликации обладает собственной информацией (называется областью видимости информации). Получается, что консолидировання БД содержит все записи, а удаленные только те, которые им полагаются. В ASA область видимости информации может разделяться между несколькими узлами или только одним. Организуется это дополнительным полем на такую информацию. Например в таблице Orders есть поле "КодУзла", который однозначно идентифицирует, какому офису была выписана накладная на товар. Указав в на Orders SUBSCRIBE BY КодУзла мы говорим ASA автоматически разделять информацию подписчикам - при подписке они указывают свой номер узла и автоматически при репликации информация распределяется по нужным узлам. Помимо указания поля в репликации мы можем указывать запрос для получения кода узла. Это полезно, чтобы на каждую таблицу не вешать такое поле. Например в таблице Orders есть ссылка на таблицу Cars (поле КодМашины), т.е. помимо накладной указано, какая машина будет доставлять груз и нам необходимо переслать информацию по машинам из таблицы Cars только по тем офисам, куда они едут. В таком случае мы вешаем SUBSCRIBE BY (SELECT КодУзла FROM Orders WHERE КодМашины = Cars.КодМашины). Для каждой реплицируемой записи по таблице Cars ASA будет вызывать этот запрос и таким образом получать искомый код узла, далее уже по обычной схеме смотреть, какие подписчики указали этот код узла и отправлять им информацию. Указанный запрос может возвращать более одной записи, таким образом если у нас одна машина "вдруг" указана в нескольких накладных для разных офисов, этим запросом будут возвращены все коды узлов, для которых должна реплицироваться запись.

P.S. Рекомендую еще почитать перевод BOL SQLRemote, который взять можно с FAQ.

Присоединяюсь к пожеланиям :)

У меня примерно так же сделано - в консолидированной БД есть все, что в удаленных, кроме вспомогательной информации.

Реализовано дерево подключений узлов (удаленных БД) и расширения прав доступа, где на логические режимы программы (помимо собственно разрешений по GRANT) расписаны группы прав с правами на действие (администрирование, просмотр, добавление, изменение, удаление, изм. и удал. только собств. записей). А на каждый узел для каждого пользователя указываются группа или группы прав. Соотвествующе такая схема позволяет решить 3 вещи:

1. Система одинаково работает в схеме "Консолидированная БД-репликация-Удаленная БД узла-Пользователи узла" и в схеме "Консолидированная БД-выделенный канал-Пользователи узла", причем в любой момент достаточно просто переключит режим работы узла и например перевести пользователей с репликации на прямую работу с консолидированной БД.

2. Пользователю не важно где он работает - имея расписанные права по узлам он в любой удаленной точке или консолидированной БД может продолжать свою работу. Таким образом разьезжающий по стране администратор централизованных справочников может спокойно прямо на местах их править, а пользователь удаленного узла, приехав в центр, подключится к консолидированной БД и увидеть/изменить информацию по своему узлу в пределах своих прав.

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

авторУ меня сейчас есть таблица офисов, думаю при подключении будет
возвращатся данные о юзере (кто он такой и откуда)на основе этого будут
отображатся машины которые либо созданы в его городе, либо едут в его
город, ну а с накладными вообще все просто, т.к. накладные это detail
машин, т.е. при правильном отображении машин не отобразятся левые накладные.
Только вот как можно проанализировать кто сейчас подключился и вернуть
информацию о нем?
Не нужно к пользователю привязывать показ информации. Лучше организовать, что есть табличка пользователей и дерево узлов (офисов), а так же табличка прав доступа пользователя к узлам (многие-ко-многим). Плюс в каждой БД где то хранить какой код узла она имеет. Можно написать ХП на логин, которая организует и инициализирует глобальные переменные @@КодтекущегоУзла и @@КодТекущегоПользователя, чтобы всем было удобнее работать внутри сессии. В итоге мы по коду текущего узла всегда будем знать, для какого офиса БД, а по коду текущего пользователя всегда сможем узнать, какие офисы ему доступны, а значит какую информацию по этим офисам он видит. То есть получится такой запрос на накладные:
Все это можно обернуть представлениями и ХП, которые будут строго возвращать информацию только для текущего пользователя по его правам и уже далее работать с ними. Только в представлении нельзя использовать ХП и свои глобальные переменные во избежания проблем генерации перегрузки базы данных, там лучше создать UDF, которые сейчас в ASA правильно генерятся в скрипт перезагрузки до создания представлений.

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

Dimyan
Продолжу тему чтоб не плодить однотипных.
Такую проблему заметил странную (раньше сервера включенные все время
были поэтому не замечал этого):
У меня база и dbremote запускаются автаматом как сервис, дак вот при
загрузке компа dbremote есно загружается быстрее чем поднимается база
после чего грозно ругается на меня матом и говорит что к базе не может
подключится. Можно конечно как нибкдь с nnCron извратится но должен же
быть какой то стандартный способ как запустить dbremote после загрузки базы?
Posted via ActualForum NNTP Server 1.2
Нужно создать сервис под репликацию через консольную утилиту DBSVC.EXE, указав в параметре -rs имя сервиса, который запускает сервер ASA. Правильные имена сервисов можно посмотреть в списке сервисов штатными средствами Windows.

PaulJB 2 ASCRUS
Как я понял, Dimyan-у надо вначале запустить базу, подождать до окончания запуска (сервер/база начинает отвечать на запросы), а затем уже запускать агента. Процесс запуска базы может затянуться до 30-40 сек. Все зависит от размера логов и причины предыдущего останова. Например: УПС сдох раньше, чем база смогла нормально опуститься.
Я таких утилит не встречал, которые бы поднимали базу АСА, ждали окончания процесса старта, а затем поднимали бы агента (например).
Пришлось писать свою программулину ...
Правда, сервер и агент у меня запускаются обычным образом, т.е. не как сервисы. Тут много раз обсуждались проблемы связанные с работой агента, который запущен как сервис, а при нормальном запуске проблем никогда не возникало (по крайней мере у меня).
Указание зависимостей сервисов именно это и делает в Windows - сервис ожидает, пока его все родителькие сервисы полностью запустяться и только после этого стартует. Другое дело, когда ASA дает Windows понять, что сервис уже запущен - сразу как поднялся сервер или же как все БД перешли в онлайн, это нужно проверять.