Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
28.03.2005, 08:28
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
ASA 9.0 dbremote При репликации на нижнем уровне удаляются записи из таблицы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 09:23
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
информации маловато. Может в Articles какие-либо доп. условия прописаны, которые по прибытии не удовлетворяют условиям в удаленных базах... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 09:45
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
Вроде нет 1. Есть таблица (tr) куда пишется движения по складу, на ней висит тригер который вносит соответствующие изминения в состояние склада 2. Реплицируется таблица tr снизу вверх. Ситуация: На центральной базе дали что то на склад удаленному пользователю (П1) Он у себя запускает dbremote . К нему все пришло хорошо Теперь он у себя часть товара передает на склад своего работника (р1) Выполняет репликацию на центральную базу Туда приходит все нормально. Теперь из центральной идет ответ И после его приема на удалунной базе из таблицы tr удаляются записи пользователя П1 которые ушли на Р1. Хотя на центральной базе есть записи и на П1 и на Р1 Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 09:58
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
из личного опыта, если в других таблицах все нормально, то смотрите тригеры... скорее всего там где-то что-то... попробуйте досконально проиграть сценарий. Кстати, Replicate all triggers в dbremote используется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 10:43
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
Организовал подобную ситуацию на других таблицах. Тот же результат . Наверное в настройках может быть проблема ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 10:58
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
Рыжий Котинформации маловато. Может в Articles какие-либо доп. условия прописаны, которые по прибытии не удовлетворяют условиям в удаленных базах... точно... мне кажеться что "удаляются записи пользователя П1 которые ушли на Р1" из-за того что они не попадают под условия подписки для П1 в консалидир. базе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 11:15
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
Спасибо Есть еще пуликация которая дает П1 строки по реестру Но тогда как указать еще что Р1 принадлежит П1 или наверное как запретить передачу сообщений на П1 если они пришли от него Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 11:17
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
еще отдельная публикация на центральной базе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 12:05
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
Ошибку нашел теперь встает вопрос как сделать чтоб одна таблица реплицироваласть сверху вниз при определенном услаовии а снизу вверх полностью, кроме записей что пришли к ней сверху Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 12:54
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
Mykola...как сделать чтоб одна таблица реплицироваласть сверху вниз при определенном услаовии а снизу вверх полностью, кроме записей что пришли к ней сверху Спасибо Сверху вниз можно сделать, организовав набор правил в статьях. А вот снизу вверх - не совсем понял. Вы не хотите, чтобы переданные данные из консолидированной базы не вернулись обратно, если их кто-то изменит в удаленной базе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 12:56
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
сори одно "не" лишнее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 13:22
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
они внизу не изменяются только передаются другим контрагентам (что то на подобие передача с одного склада на другой) и теперь это передача поднимается наверх по описаному мной все сделал работает за исключением того что вторая публикация по таблице на центральной базе дает удаление о чем писал выше. На центральной базе данные все ок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 13:30
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
краткое описание как сделано 1. есть созданы две таблицы CREATE TABLE "zagal"."tbl_reestr" ("id_reestr" uniqueidentifier NOT NULL DEFAULT newid(*), "id_typepolis" integer DEFAULT NULL, "id_buyer_of" uniqueidentifier DEFAULT NULL, "series" char(5) DEFAULT NULL, "numberpolis" integer DEFAULT NULL, "getdate" date DEFAULT NULL, "agdate" date DEFAULT NULL, "status" integer DEFAULT NULL, "numberact" integer DEFAULT NULL, "id_buyer_to" uniqueidentifier DEFAULT NULL, "representative_firma" varchar(100) DEFAULT NULL, "post_representative_firma" varchar(100) DEFAULT NULL, "representative_buyer" varchar(100) DEFAULT NULL, "post_representative_buyer" varchar(100) DEFAULT NULL , PRIMARY KEY ("id_reestr") , FOREIGN KEY "fk_tbl_rees_reference_tbl_buye" ("id_buyer_of" ) REFERENCES "info"."tbl_buyer" ON DELETE RESTRICT , FOREIGN KEY "fk_tbl_rees_reference_tbl_type" ("id_typepolis" ) REFERENCES "info"."tbl_typepolis" ON DELETE RESTRICT ) ; CREATE UNIQUE INDEX "ii_reestrid" ON "zagal"."tbl_reestr" ("id_reestr" ) ; CREATE UNIQUE INDEX "tbl_reestr unique (id_reestr)" ON "zagal"."tbl_reestr" ("id_reestr" ) ; CREATE TABLE "zagal"."tbl_sclad" ("id_sclad" uniqueidentifier NOT NULL DEFAULT newid(*), "id_typepolis" integer DEFAULT NULL, "id_buyer" uniqueidentifier DEFAULT NULL, "series" char(5) DEFAULT NULL, "numberpolis" integer DEFAULT NULL, "getdate" date DEFAULT NULL, "agdate" date DEFAULT NULL , PRIMARY KEY ("id_sclad") , FOREIGN KEY "fk_tbl_scla_reference_tbl_buye" ("id_buyer" ) REFERENCES "info"."tbl_buyer" ON DELETE RESTRICT ) ; CREATE UNIQUE INDEX "ii_scladid" ON "zagal"."tbl_sclad" ("id_sclad" ) ; CREATE UNIQUE INDEX "tbl_sclad unique (id_sclad)" ON "zagal"."tbl_sclad" ("id_sclad" ) ; 2. На тблице "zagal"."tbl_reestr" есть триггер: ALTER TRIGGER "tr_ocv_receipt_sclad_firmu" AFTER INSERT ORDER 1 ON "zagal"."tbl_reestr" REFERENCING NEW AS new_name FOR EACH ROW /* WHEN( search_condition ) */ BEGIN declare vi_control integer; if new_name.status = 1 then insert into zagal.tbl_sclad( id_sclad, id_typepolis, id_buyer, series, numberpolis, getdate, agdate ) values(new_name.id_reestr, new_name.id_typepolis, new_name.id_buyer_to, new_name.series, new_name.numberpolis, new_name.getdate, new_name.agdate ) elseif new_name.status = 2 /* vudacha polisiv buyer */ then set vi_control = 0; select count(s.numberpolis) into vi_control from zagal.tbl_sclad as s where s.numberpolis = new_name.numberpolis and s.id_typepolis = new_name.id_typepolis ; if vi_control = 0 then insert into zagal.tbl_sclad( id_sclad, id_typepolis, id_buyer, series, numberpolis, getdate, agdate ) values(new_name.id_reestr, new_name.id_typepolis, new_name.id_buyer_to, new_name.series, new_name.numberpolis, new_name.getdate, new_name.agdate ) else update zagal.tbl_sclad set id_buyer = new_name.id_buyer_to, agdate = new_name.agdate where numberpolis = new_name.numberpolis and series = new_name.series and id_typepolis = new_name.id_typepolis and id_buyer = new_name.id_buyer_of end if elseif new_name.status = - 1 then update zagal.tbl_sclad set id_buyer = new_name.id_buyer_to, agdate = new_name.agdate, getdate = new_name.getdate where numberpolis = new_name.numberpolis and series = new_name.series and id_typepolis = new_name.id_typepolis and id_buyer = new_name.id_buyer_of end if END 3. Публикация сверху вниз CREATE PUBLICATION pu_reestrtobuttom ( TABLE "zagal"."tbl_reestr" SUBSCRIBE BY id_buyer_to ) 4. Публикация снизу вверх CREATE PUBLICATION pu_reestrtobuttom ( TABLE "zagal"."tbl_reestr" ) 5. Пользователи подписаны соответствующим образом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 14:14
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
Мельком глянул. Проверить пока не могу, но скорее всего где-то меняется id_buyer_to. Проверьте, точно ли данного remote user-a остаются записи с НУЖНЫМ id_buyer_to. Скорее всего они меняются. А раз меняются, то соответствующий remote user не должен их видеть, вот они и уничтожаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2005, 15:00
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
да он меняется но как в публикации сверху вниз включить его есть процедура которая формирует кто подчиняется даному id_buyer как ее можна прописать в условии публикации и передать ей параметром id_buyer для которых формировать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2005, 10:19
|
|||
|---|---|---|---|
remote. Help me |
|||
|
#18+
Проделал все указаные замечания, попробовал еще ряд условий. Но проблему не удалось решить. И дальше записи что пришли с нижнего уровня, которые там были переданы другому контрагенту, на центральную базу, при репликации с центральной базой в следующий раз удаляются на базе нижнего уровня Буду благодарен за помощь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2005, 17:46
|
|||
|---|---|---|---|
|
|||
remote. Help me |
|||
|
#18+
Mykola И дальше записи что пришли с нижнего уровня, которые там были переданы другому контрагенту, на центральную базу, при репликации с центральной базой в следующий раз удаляются на базе нижнего уровня Похоже эти записи удаляется, так как на консолидираванной базе изменяется id_buyer_to. Они не соответствуют SYBSCRIBE BY и для сохранения целостности данных во всех БД, SQL Remote отправляет команду удаления этих записей. И правильно, т.к. если id_buyer_to изменится еще раз в консолидированной базе, то удаленная эти изменения не получит и данные базах будут различаться. Mykola но как в публикации сверху вниз включить его есть процедура которая формирует кто подчиняется даному id_buyer Попробуй в CREATE PUBLICATION вместо SYBSCRIBE BY использовать WHERE со своей процедурой проверки "кто подчиняется даному id_buyer". для идентификации, кому будут отправлены данные, можно попробовать использовать CURRENT REMOTE USER. Мое имхо - правильнее было бы переделать структуру БД. Как-то мохнато все это выглядит для решения такой задачи. Вероятно, при разработке не планировалось использовать SQL Remote. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2005, 19:44
|
|||
|---|---|---|---|
|
|||
remote. Help me |
|||
|
#18+
Basilisk для идентификации, кому будут отправлены данные, можно попробовать использовать CURRENT REMOTE USER. Тысяча извинений. Нельзя использовать CURRENT REMOTE USER для WHERE в PUBLICATION CURRENT REMOTE USER в этом случае всегда будет NULL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=55&mobile=1&tid=2013755]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
| others: | 247ms |
| total: | 417ms |

| 0 / 0 |
