Поскольку все наши специалисты по таможенным операциям работают в общей базе Монитора-ЭД (плюсов, на мой взгляд, от этого всё же больше чем минусов) - эту самую базу приходится регулярно чистить, ибо когда размер её превышает 1-1,5 гигабайта - начинаются лютые, бешеные тормоза (в лучшем случае) или же монитор сыплет ошибками (exception из за таймаутов - в худшем случае). Техподдержка уверяет что всё это из за MS SQL Express и ограничений оного на потребление ОЗУ, но нам от этого не легче. В общем, каждые 1-2 месяца из базы удаляются записи по старым завершённым процедурам. Удаляются, понятно, не абы как а с бекапом. Причём изредка возникает необходимость что-то из этого бекапа восстановить - бывает, нужно сделать корректировку по декларации, для которой процедура обмена вроде бы завершена.
Так вот, обычно всё это проблем не вызывает - специалист по ТО или сам заранее просит проверить можно ли работать с такой старой декларацией, либо, если ему всё до лампочки - пытается отправлять по ней сообщения, получает кучу ошибок из АСТО и в панике набигает на серверную. В любом случае - кто-нибудь из админов просто восстанавливает сообщения в базу из бекапа, потом если специалист успел поломать статус обмена - восстанавливает его - и можно работать.
Сегодня вылезает грабля. "CMN.00001, Ошибка при контроле сообщения/ выполнении операции, 02.00082.01, Указан несуществующий идентификатор процедуры." - сообщает АСТО в ответ на попытку отправить модифицированный набор документов.
Попытки подключить логику а также метод научного тыка успеха не приносят, звоним в техподдержку. СТМ-щик, подключившись тимвиером - выполняет следующие шаманские действия: удаляет полностью протокол обмена из базы монитора, запрашивает историю, запрашивает повтор всех сообщений декларации. После чего модифицированный набор спокойно уходит. Но как работает это шаманство - непонятно, СТМ-щик ничего вразумительного тоже сказать не может. Так надо. Работает же :).
Через полчаса проблема повторяется и на этот раз шаманство, исполненное локальным админом - не помогает. И вот теперь повторное подключение логики (попытка сравнить нормальный модифицированный набор и "больной") даёт следующее открытие - оказывается внутри xml-сообщения в одном из узлов указан не тот код поста! Он никак не связан с кодом поста в номере декларации, хранится в базе монитора и, внимание - однократно запрашивается у пользователя в том случае, если он пытается что-то сделать с декларацией, по которой в базе монитора ничего нет. Именно поэтому в первом шаманском эпизоде (когда код был указан правильно) всё прошло идеально, а во втором (юзер не глядя на окошки ткнул ОК, а там был подставлен пост по-умолчанию из настроек) - "всё сломалось".
Итого, нет никакого смысла изображать из себя шимпандзе и повторять за техподдержкой - достаточно просто удалить из базы монитора созданные юзером сообщения с неправильным кодом поста (без бекапа или с бекапом в отдельное место!), потом восстановить сообщения по декларации из основного бекапа (при этом восстановится правильный код поста) и, при необходимости - запросить историю и отсутствующие сообщения. На самом деле очень не хватает возможности сменить код поста прямо из интерфейса Монитора-ЭД.
Как то так :).
