Цитата:
Сообщение от
Андрей К.
вот в случае с таблицами синхронизацию надо применять
О, да!
Вспомнилось, как однажды было добавлено поле в одну из тех таблиц, которые синхронизируются при старте сессии. На одном АОСе синхронизировали таблицу после создания поля - оно в базе появилось, на другой АОС зашел пользователь, табличка синхронизировалась - поле из базы пропало, и так ндцать раз...
А еще очень "весело" может получиться, если добавить поле в таблицу, которая постоянно используется в приложении (какая-нить SalesParameters): добавили, не успели синхронизироваться, зашел пользователь, "увидел", что в таблице новое поле, давай его указывать в select'ах, а СУБД грит, отвали, нету такого поля в таблице - и так у пользователя на любой чих начинает лезть ошибка, и ничего не работает.
Это я все к тому, что на рабочей базе при нескольких работающих АОСах и работающих пользователях схему данных лучше не менять - вообще. Ну либо очень хорошо взвешивать все "за" и "против".
Цитата:
Сообщение от
DSPIC
В каждом из этих случаев "взводится" соответствующая команда всем АОСам через вызов SysEvent::fireEvent(SysEventType::XXXXXX), где XXXXXX = [FlushAOD | FlushData | FlushDictionary | ...]);
К сожалению, это все не поможет обновить кэш объектов приложения на клиентах. Я как-то под отладчиком наблюдал, как мне прежде казалось, совершенно невероятную ситуацию: класс-наследник RunBase переключался между клиентом и сервером, там и там дергая определенный метод (кажется, это был validate), и при этом на клиенте код этого метода был один, а на сервере - другой. Так что кэширование кода на клиентах - штука опасная, и забывать про него нельзя.