| Цитата |
|---|
| написал: НО!!! от идеи вызова макроса через триггер СУБД пришлось отказаться: 1. Надо правильно организовать сам триггер, чтобы не получилось замкнутого круга: пользователь что-то сделал, вызывается триггер. Он что-то делает с данными (к примеру) и вызывает сам себя. В этом случае Ваша БД просто зависнет и придется делать рестарт службы. 2. Пока макрос от триггера не отработает, таблицей нельзя будет пользоваться: получать и править информацию не получится. Не один раз было у меня такое, что по разным причинам макрос застревал или что-то еще не получалось, как итог пришлось делать рестарт СУБД. 3. Как и с автообновлением могут возникнуть проблемы с производительностью. Так например, если в слое больше 3-5 тыс объектов, то приходиться отключать автообновление, а то при каждом новом событии, весь слой подвисает на секунду и больше. Если с этим слоем работают несколько человек, при этом что-то внося, то работать становиться невозможно. Тоже самое и с триггером, который запускает обновление темы, при частых срабатываниях (раз в пару секунд) и большом количестве объектов работать станет невыносимо. Вообще автообновление может тормозить слой на секунд 30, даже если в самом слое пару объектов. Может баг, но очень много проблем в один день принесло, остановило работу на пол дня, а я в отъезде был)) В итоге что делаю: с помощью планировщика задач, делаю задачу на запуск макроса каждую ночью. В большинстве проектов этого достаточно Если же требуется обновлять часто, особенно это касается проектов по инвентаризации, то ставим задачу с интервалом в 5-10 минут. В этом случае ничего не виснет, а темы обновляются с приемлемым интервалом. *** Весь SQL учил по интернету, так что не удивлюсь, если я что-то делал не так с триггерами и получал зависания. Буду очень рад, если кто-то напишет, как лучше вызывать макросы триггером, при этом безопасно. |
Themes.UpdateForOneElem(long ElemID, long ThemeId, long BaseID, BSTR QueryName, BSTR Fields, long Flags, long* pRetVal);
Сейчас Fields = "", Flags = 0