RUS  ENG 

Обновление тематической раскраски

Страницы: 1
RSS
Обновление тематической раскраски
 
Добрый день, при внесении данных в базу слоя через стороннее приложение тематическая раскраска не реагирует на изменение данных, может быть у кого-нибудь есть готовое решение данного вопроса, которым готовы поделиться.
 
Цитата
написал:
Добрый день, при внесении данных в базу слоя через стороннее приложение тематическая раскраска не реагирует на изменение данных, может быть у кого-нибудь есть готовое решение данного вопроса, которым готовы поделиться.
Добрый день! Готового решения нет. база к системе прямого отношения не имеет. Поэтому, если данные менять со стороны, система об этом знать не может. Нужно подать ей сигнал. Некоторые для этого используют триггеры в СУБД.
 
Цитата
написал:
Цитата
написал:
Добрый день, при внесении данных в базу слоя через стороннее приложение тематическая раскраска не реагирует на изменение данных, может быть у кого-нибудь есть готовое решение данного вопроса, которым готовы поделиться.
Добрый день! Готового решения нет. база к системе прямого отношения не имеет. Поэтому, если данные менять со стороны, система об этом знать не может. Нужно подать ей сигнал. Некоторые для этого используют триггеры в СУБД.
На триггер в СУБД к сожалению фильтр не реагирует, может быть есть ещё варианты?
 
Цитата
написал:
Цитата
написал:
Добрый день! Готового решения нет. база к системе прямого отношения не имеет. Поэтому, если данные менять со стороны, система об этом знать не может. Нужно подать ей сигнал. Некоторые для этого используют триггеры в СУБД.
На триггер в СУБД к сожалению фильтр не реагирует, может быть есть ещё варианты?
А что триггер делает? Там нужно вызвать процедуру, которая бы, например, раскраску обновила
 
Цитата
написал:
Цитата
написал:
Цитата
написал:
Добрый день, при внесении данных в базу слоя через стороннее приложение тематическая раскраска не реагирует на изменение данных, может быть у кого-нибудь есть готовое решение данного вопроса, которым готовы поделиться.
Добрый день! Готового решения нет. база к системе прямого отношения не имеет. Поэтому, если данные менять со стороны, система об этом знать не может. Нужно подать ей сигнал. Некоторые для этого используют триггеры в СУБД.
На триггер в СУБД к сожалению фильтр не реагирует, может быть есть ещё варианты?
Расскажу свой опыт использования триггеров на обновление тематических раскрасок:
Видео для примера: https://youtu.be/80YzEfD3pMY
После выбора пункта проверка в слое граница, запускался триггер на стороне СУБД, который вызывал макрос, который связывал объекты и делалась проверка. Также обновлялась раскраска. Заметьте, что вызов самого триггера происходит в другом слое, в другой таблице - это важно!

НО!!!

от идеи вызова макроса через триггер СУБД пришлось отказаться:

1. Надо правильно организовать сам триггер, чтобы не получилось замкнутого круга: пользователь что-то сделал, вызывается триггер. Он что-то делает с данными (к примеру) и вызывает сам себя. В этом случае Ваша БД просто зависнет и придется делать рестарт службы.

2. Пока макрос от триггера не отработает, таблицей нельзя будет пользоваться: получать и править информацию не получится. Не один раз было у меня такое, что по разным причинам макрос застревал или что-то еще не получалось, как итог пришлось делать рестарт СУБД.

3. Как и с автообновлением могут возникнуть проблемы с производительностью. Так например, если в слое больше 3-5 тыс объектов, то приходиться отключать автообновление, а то при каждом новом событии, весь слой подвисает на секунду и больше. Если с этим слоем работают несколько человек, при этом что-то внося, то работать становиться невозможно. Тоже самое и с триггером, который запускает обновление темы, при частых срабатываниях (раз в пару секунд) и большом количестве объектов работать станет невыносимо.

Вообще автообновление может тормозить слой на секунд 30, даже если в самом слое пару объектов. Может баг, но очень много проблем в один день принесло, остановило работу на пол дня, а я в отъезде был))

В итоге что делаю: с помощью планировщика задач, делаю задачу на запуск макроса каждую ночью. В большинстве проектов этого достаточно
Если же требуется обновлять часто, особенно это касается проектов по инвентаризации, то ставим задачу с интервалом в 5-10 минут. В этом случае ничего не виснет, а темы обновляются с приемлемым интервалом.

*** Весь SQL учил по интернету, так что не удивлюсь, если я что-то делал не так с триггерами и получал зависания.

Буду очень рад, если кто-то напишет, как лучше вызывать макросы триггером, при этом безопасно.
 
Цитата
написал:
Цитата
написал:
Цитата
написал:
Цитата
написал:
Добрый день, при внесении данных в базу слоя через стороннее приложение тематическая раскраска не реагирует на изменение данных, может быть у кого-нибудь есть готовое решение данного вопроса, которым готовы поделиться.
Добрый день! Готового решения нет. база к системе прямого отношения не имеет. Поэтому, если данные менять со стороны, система об этом знать не может. Нужно подать ей сигнал. Некоторые для этого используют триггеры в СУБД.
На триггер в СУБД к сожалению фильтр не реагирует, может быть есть ещё варианты?
Расскажу свой опыт использования триггеров на обновление тематических раскрасок:
Видео для примера: https://youtu.be/80YzEfD3pMY
После выбора пункта проверка в слое граница, запускался триггер на стороне СУБД, который вызывал макрос, который связывал объекты и делалась проверка. Также обновлялась раскраска. Заметьте, что вызов самого триггера происходит в другом слое, в другой таблице - это важно!

НО!!!

от идеи вызова макроса через триггер СУБД пришлось отказаться:

1. Надо правильно организовать сам триггер, чтобы не получилось замкнутого круга: пользователь что-то сделал, вызывается триггер. Он что-то делает с данными (к примеру) и вызывает сам себя. В этом случае Ваша БД просто зависнет и придется делать рестарт службы.

2. Пока макрос от триггера не отработает, таблицей нельзя будет пользоваться: получать и править информацию не получится. Не один раз было у меня такое, что по разным причинам макрос застревал или что-то еще не получалось, как итог пришлось делать рестарт СУБД.

3. Как и с автообновлением могут возникнуть проблемы с производительностью. Так например, если в слое больше 3-5 тыс объектов, то приходиться отключать автообновление, а то при каждом новом событии, весь слой подвисает на секунду и больше. Если с этим слоем работают несколько человек, при этом что-то внося, то работать становиться невозможно. Тоже самое и с триггером, который запускает обновление темы, при частых срабатываниях (раз в пару секунд) и большом количестве объектов работать станет невыносимо.

Вообще автообновление может тормозить слой на секунд 30, даже если в самом слое пару объектов. Может баг, но очень много проблем в один день принесло, остановило работу на пол дня, а я в отъезде был))

В итоге что делаю: с помощью планировщика задач, делаю задачу на запуск макроса каждую ночью. В большинстве проектов этого достаточно
Если же требуется обновлять часто, особенно это касается проектов по инвентаризации, то ставим задачу с интервалом в 5-10 минут. В этом случае ничего не виснет, а темы обновляются с приемлемым интервалом.

*** Весь SQL учил по интернету, так что не удивлюсь, если я что-то делал не так с триггерами и получал зависания.

Буду очень рад, если кто-то напишет, как лучше вызывать макросы триггером, при этом безопасно.
Может быть Вам не трудно будет поделиться текстом триггера и макроса на этом форуме?
 
Цитата
написал:

НО!!!

от идеи вызова макроса через триггер СУБД пришлось отказаться:

1. Надо правильно организовать сам триггер, чтобы не получилось замкнутого круга: пользователь что-то сделал, вызывается триггер. Он что-то делает с данными (к примеру) и вызывает сам себя. В этом случае Ваша БД просто зависнет и придется делать рестарт службы.

2. Пока макрос от триггера не отработает, таблицей нельзя будет пользоваться: получать и править информацию не получится. Не один раз было у меня такое, что по разным причинам макрос застревал или что-то еще не получалось, как итог пришлось делать рестарт СУБД.

3. Как и с автообновлением могут возникнуть проблемы с производительностью. Так например, если в слое больше 3-5 тыс объектов, то приходиться отключать автообновление, а то при каждом новом событии, весь слой подвисает на секунду и больше. Если с этим слоем работают несколько человек, при этом что-то внося, то работать становиться невозможно. Тоже самое и с триггером, который запускает обновление темы, при частых срабатываниях (раз в пару секунд) и большом количестве объектов работать станет невыносимо.

Вообще автообновление может тормозить слой на секунд 30, даже если в самом слое пару объектов. Может баг, но очень много проблем в один день принесло, остановило работу на пол дня, а я в отъезде был))

В итоге что делаю: с помощью планировщика задач, делаю задачу на запуск макроса каждую ночью. В большинстве проектов этого достаточно
Если же требуется обновлять часто, особенно это касается проектов по инвентаризации, то ставим задачу с интервалом в 5-10 минут. В этом случае ничего не виснет, а темы обновляются с приемлемым интервалом.

*** Весь SQL учил по интернету, так что не удивлюсь, если я что-то делал не так с триггерами и получал зависания.

Буду очень рад, если кто-то напишет, как лучше вызывать макросы триггером, при этом безопасно.
Если известно, для какого объекта запись менялась (Sys) и для какой раскраски нужно обновление, иногда эффективней обновить раскраску только для одного объекта

Themes.UpdateForOneElem(long ElemID, long ThemeId, long BaseID, BSTR QueryName, BSTR Fields, long Flags, long* pRetVal);

Сейчас Fields = "", Flags = 0
 
Цитата
написал:
Цитата
написал:
Цитата
написал:
Цитата
написал:
Цитата
написал:
Добрый день, при внесении данных в базу слоя через стороннее приложение тематическая раскраска не реагирует на изменение данных, может быть у кого-нибудь есть готовое решение данного вопроса, которым готовы поделиться.
Добрый день! Готового решения нет. база к системе прямого отношения не имеет. Поэтому, если данные менять со стороны, система об этом знать не может. Нужно подать ей сигнал. Некоторые для этого используют триггеры в СУБД.
На триггер в СУБД к сожалению фильтр не реагирует, может быть есть ещё варианты?
Расскажу свой опыт использования триггеров на обновление тематических раскрасок:
Видео для примера: https://youtu.be/80YzEfD3pMY
После выбора пункта проверка в слое граница, запускался триггер на стороне СУБД, который вызывал макрос, который связывал объекты и делалась проверка. Также обновлялась раскраска. Заметьте, что вызов самого триггера происходит в другом слое, в другой таблице - это важно!

НО!!!

от идеи вызова макроса через триггер СУБД пришлось отказаться:

1. Надо правильно организовать сам триггер, чтобы не получилось замкнутого круга: пользователь что-то сделал, вызывается триггер. Он что-то делает с данными (к примеру) и вызывает сам себя. В этом случае Ваша БД просто зависнет и придется делать рестарт службы.

2. Пока макрос от триггера не отработает, таблицей нельзя будет пользоваться: получать и править информацию не получится. Не один раз было у меня такое, что по разным причинам макрос застревал или что-то еще не получалось, как итог пришлось делать рестарт СУБД.

3. Как и с автообновлением могут возникнуть проблемы с производительностью. Так например, если в слое больше 3-5 тыс объектов, то приходиться отключать автообновление, а то при каждом новом событии, весь слой подвисает на секунду и больше. Если с этим слоем работают несколько человек, при этом что-то внося, то работать становиться невозможно. Тоже самое и с триггером, который запускает обновление темы, при частых срабатываниях (раз в пару секунд) и большом количестве объектов работать станет невыносимо.

Вообще автообновление может тормозить слой на секунд 30, даже если в самом слое пару объектов. Может баг, но очень много проблем в один день принесло, остановило работу на пол дня, а я в отъезде был))

В итоге что делаю: с помощью планировщика задач, делаю задачу на запуск макроса каждую ночью. В большинстве проектов этого достаточно
Если же требуется обновлять часто, особенно это касается проектов по инвентаризации, то ставим задачу с интервалом в 5-10 минут. В этом случае ничего не виснет, а темы обновляются с приемлемым интервалом.

*** Весь SQL учил по интернету, так что не удивлюсь, если я что-то делал не так с триггерами и получал зависания.

Буду очень рад, если кто-то напишет, как лучше вызывать макросы триггером, при этом безопасно.
Может быть Вам не трудно будет поделиться текстом триггера и макроса на этом форуме?
Макрос:


Sub update_theme
Set L = CreateObject("ZuluLib.Layer")
L.open "zulu://login:password@localhost:6477/2022/Серпухов/Слои/Здания.zl"
L.Themes.UpdateTheme(1)
End Sub

Думаю по макросу все понятно, если что гляньте документацию.

Триггер:

create trigger [dbo].[update_theme]
on [dbo].[stats_border]
for update
as
IF (UPD ATE(update_theme) and (sel ect top(1) update_theme fr om inserted) = 'Обновить' )
begin
update [stats_border]
se t update_theme = null
exec master..xp_cmdshell 'D:\Zulu\SQL_VBS_BAT\update_theme.bat'
end
Изменено: Сергей Мечев - 24.06.2022 13:22:53
 
Цитата
написал:
Цитата
написал:
Цитата
написал:
Цитата
написал:
Цитата
написал:
Цитата
написал:
Добрый день, при внесении данных в базу слоя через стороннее приложение тематическая раскраска не реагирует на изменение данных, может быть у кого-нибудь есть готовое решение данного вопроса, которым готовы поделиться.
Добрый день! Готового решения нет. база к системе прямого отношения не имеет. Поэтому, если данные менять со стороны, система об этом знать не может. Нужно подать ей сигнал. Некоторые для этого используют триггеры в СУБД.
На триггер в СУБД к сожалению фильтр не реагирует, может быть есть ещё варианты?
Расскажу свой опыт использования триггеров на обновление тематических раскрасок:
Видео для примера: https://youtu.be/80YzEfD3pMY
После выбора пункта проверка в слое граница, запускался триггер на стороне СУБД, который вызывал макрос, который связывал объекты и делалась проверка. Также обновлялась раскраска. Заметьте, что вызов самого триггера происходит в другом слое, в другой таблице - это важно!

НО!!!

от идеи вызова макроса через триггер СУБД пришлось отказаться:

1. Надо правильно организовать сам триггер, чтобы не получилось замкнутого круга: пользователь что-то сделал, вызывается триггер. Он что-то делает с данными (к примеру) и вызывает сам себя. В этом случае Ваша БД просто зависнет и придется делать рестарт службы.

2. Пока макрос от триггера не отработает, таблицей нельзя будет пользоваться: получать и править информацию не получится. Не один раз было у меня такое, что по разным причинам макрос застревал или что-то еще не получалось, как итог пришлось делать рестарт СУБД.

3. Как и с автообновлением могут возникнуть проблемы с производительностью. Так например, если в слое больше 3-5 тыс объектов, то приходиться отключать автообновление, а то при каждом новом событии, весь слой подвисает на секунду и больше. Если с этим слоем работают несколько человек, при этом что-то внося, то работать становиться невозможно. Тоже самое и с триггером, который запускает обновление темы, при частых срабатываниях (раз в пару секунд) и большом количестве объектов работать станет невыносимо.

Вообще автообновление может тормозить слой на секунд 30, даже если в самом слое пару объектов. Может баг, но очень много проблем в один день принесло, остановило работу на пол дня, а я в отъезде был))

В итоге что делаю: с помощью планировщика задач, делаю задачу на запуск макроса каждую ночью. В большинстве проектов этого достаточно
Если же требуется обновлять часто, особенно это касается проектов по инвентаризации, то ставим задачу с интервалом в 5-10 минут. В этом случае ничего не виснет, а темы обновляются с приемлемым интервалом.

*** Весь SQL учил по интернету, так что не удивлюсь, если я что-то делал не так с триггерами и получал зависания.

Буду очень рад, если кто-то напишет, как лучше вызывать макросы триггером, при этом безопасно.
Может быть Вам не трудно будет поделиться текстом триггера и макроса на этом форуме?
Макрос:


Sub update_theme
Set L = CreateObject("ZuluLib.Layer")
L.open "zulu://login:password@localhost:6477/2022/Серпухов/Слои/Здания.zl"
L.Themes.UpdateTheme(1)
End Sub

Думаю по макросу все понятно, если что гляньте документацию.

Триггер:

create trigger [dbo].[update_theme]
on [dbo].[stats_border]
for update
as
IF (UPD ATE(update_theme) and (sel ect top(1) update_theme fr om inserted) = 'Обновить' )
begin
update [stats_border]
se t update_theme = null
exec master..xp_cmdshell 'D:\Zulu\SQL_VBS_BAT\update_theme.bat'
end
При вставке триггера, форум добавил пробелы кое-где, их убрать не удается))
 
Сергей Мечев, спасибо за интересное решение, по тексту макроса всё понятно, не совсем понятно как он запускается. Насколько я знаю файл макроса имеет расширение .vbs, у вас он запускается файлом update_theme.bat., как это работает?
 
Цитата
написал:
Сергей Мечев , спасибо за интересное решение, по тексту макроса всё понятно, не совсем понятно как он запускается. Насколько я знаю файл макроса имеет расширение .vbs, у вас он запускается файлом update_theme.bat., как это работает?
Триггер на стороне mssql запускает бат файл. Сам бат файл написал ниже:

rem For 32-bit OS
Set "SystemPath=%SystemRoot%\System32"

rem If 64-bit OS
if exist %SystemRoot%\SysWOW64 set "SystemPath=%SystemRoot%\SysWow64"

%SystemPath%\cscript.exe D:\Zulu\SQL_VBS_BAT\update_theme_tbo.vbs

Сам бат файл скопировал отсюда:
https://www.politerm.com/articles/dev/object_model_in_bat/?sphrase_id=66934
 
При запуске скрипта вне ZuluGis у меня выходит ошибка, хотя если выполнить его в ZuluGis то всё работает. Похоже ещё долго с бубном танцевать придется для решения казалось бы элементарной задачи.
 
Цитата
написал:
При запуске скрипта вне ZuluGis у меня выходит ошибка, хотя если выполнить его в ZuluGis то всё работает. Похоже ещё долго с бубном танцевать придется для решения казалось бы элементарной задачи.
по опыту на что обратить внимание:
1. разделители системы (смотреть в форматах даты, время и т.д.)
2. кодировка бат файла и vbs (ANSI, UTF)
3. Думаю у разработчиков тоже можно спросить.
Есть одна компания, на их сервере тоже есть ошибка с запуском через бат файл, но устранить не получилось. Все перепробовали, хотя ровно такие же файлы у меня работают.
 
Цитата
написал:
При запуске скрипта вне ZuluGis у меня выходит ошибка, хотя если выполнить его в ZuluGis то всё работает. Похоже ещё долго с бубном танцевать придется для решения казалось бы элементарной задачи.
Макрос из Zulu сохраняется в UTF-8. Там у файла первые три символа EF BB BF. Из командной строки Windows эти символы воспринимает буквально, как мусор.
Нужно скопировать текст макроса в буфер обмена вставить в тектовом редакторе и сохранить как ASCII
Изменено: Алексей Аширов - 15.07.2022 15:14:39
Страницы: 1