23.01.2004, 11:40 | #1 |
Участник
|
Опять про кэш (*.aoc)
Большинству из присутствующих на форуме известна проблема обновления приложения в 3-х уровневой конфигурации и борьбы с кэшем объектов клиента (файлов *.aoc). Можно, конечно, как предлагалось где-то на форуме удалять эти файлы вручную (а если клиентов где-то 100?!!!) или автоматически при каждом запуске клиента (bat-файл), но при этом смысл кэширивания теряется.
Предлагается следующий алгоритм: 1. Перед сборкой новой версии приложения меняем ей Build Number путем запуска Axapta c Sartup Command = setBuildNo 377-79.XX, где XX - номер нашей версии. 2. Запускаем Axapta в 2-х уровневой конфигурации - она сама запрашивает компиляцию, синхронизацию и т.п. 3 Отдаем версию клиенту (заказчику) 4. Администратор заказчика останавливает AOS (весь сервис), копирует приложение, запускает первый раз клиента с ключем Sartup Command = updateBuildNo 5. Администратор заказчика запускает 2-х уровневого клиента и производит синхронизацию БД 6. Администратор заказчика запускает AOS 7. Пользователи начинают работать с системой. К сожалению, возникают ситуации, когда объект, сохраненный в кэше клиента отличается от объекта в новом приложении и приложение начинает вести себя, мягко говоря, странно. Для решения этой проблемы предлагается следующее: в классе Application объявляются 2 статических метода: PHP код:
пишем: [/PHP] if (Application::clientApplicationBuildNo() != Application::serverApplicationBuildNo()) { Args args; info("Обнаружена новая версия приложения."); SysFlushAOD::main(args); SysFlushData::main(args); SysFlushDictionary::main(args); } [/PHP] К сожалению, этот метод тоже не всегда срабатывает. Предполагаю, что он не срабатывает, когда в кэше клиента отсутствует метод clientApplicationBuildNo(). Вопрос: Можно-ли проверить наличие в кэше клиента определенного объекта? В данном случае статического метода. Если есть еще какие-либо соображения по борьбе с кэшем клиента, буду очень признателен. Да,у меня Axapta 2.5. В 3.0 - такие же проблемы? |
|