Ночью прошла загрузка. Утром пользователь построила отчеты. Она обнаружила, что один из отчетов (25 строк * 17 столбцов) содержал неправильные данные в одной строке (все столбцы). Она позвонила мне. Я сформировал отчет и данные в нем получил правильные абсолютно во всех строках. Сообщил об этом пользователю. Она сформировала повторно отчет и на этот раз получила верный результат. Пользователь прислала мне сохраненную рабочую книгу в качестве доказательства, что ее действия и до этого были верны. И действительно, никаких претензий к ней - все параметры отчета указаны правильно. В чем может быть причина такого поведения BW (с подобным я уже сталкивался раньше, но там отчет был не столь критичным; сейчас же отчет такой важности, что если данные в нем не верны, но представлены заказчику на анализ, то лучше сразу сделать пластическую операцию и эмигрировать). Чего делать-то, блин?!

в отчете не стоит признак "Новейшие данные", у пользователя в свойствах книги не стоит "обновлять данные при открытии", в момент запроса данных они еще не были перенесены из psa, запрос обрабатывался и т.д...

если критично и при этом сомневаешься в разумности действий пользователя/системы/своих разработок - отключи кэш для данного запроса. немного медленнее, зато точно будет считывать данные из куба, а не из кэша.

если запрос построен на мультике - поищи ноты - в очень специфичных ситуациях olap - процессор в этом случае не дает правильные данные. Но если патчи на систему стоят последние - то эти проблемы по идее уже решены.

Скорее всего пользователь сам лоханулся, а теперь катит бочку. Это наиболее вероятная причина. При условии, что все ошибки указанные bkmz отсутствуют.

2 Bkmz и BW-ник

Книга сдержит серию отчетов и при открытии содержит макетные данные. Пользователь вполне компетентен и самостоятельно обновляет отдельные запросы на рабочих листах при необходимости сохраняя их в локальной РК на диске. Поэтому признак "обновлять данные при открытии" неактуален, как мне кажется. Про признак "Новейшие данные" я, стыдно признаться, ничего не слышал и о том где отключать кэш для отдельного запроса тоже не знаю. Если несложно прошу пояснить где его искать. Что касемо очередной загрузки , то она гарантированно была выполнена (на 110%). Причем данные в других строках отчета все разумные, а глюк, что интересно наблюдался только в одной строке).

В дереве-структуре любого куба, в проектировщике запросов, есть такое измерение - пакет данных. в нем признак - ид. запроса. а в нем переменная - новейшие данные... Вот она тебе и нужна в фильтре.

Кэш для запроса отключается через монитор запросов (RSRT) в свойствах.

Достаточно подробно это излагается в 360м курсе...

Как все оказывается запущено...

запущенно

первый раз было правильно...

Я хороший, мне можно и простить

Нашел причину проблемы?

2 Bkmz

От пользователя жалоб не поступало пока, но они формируют отчетность не ежедневно, поэтому жду следующего раза... сейчас к сожалению нет времени разбираться - другие задачи... кэш я пока отключать не стал (будет свободная минутка, посмотрю что там сказано в 360-м курсе), а что касается самых свежих данных... то тут я тоже предпринимать ничего не стал, пока... мне кажется (просто личные домыслы), что самые свежие данные - это те которые можно читать при открытом запросе (ну что-то типа в случае транзакционного куба), но возможно я ошибаюсь... не думаю, что стандартная OLAP-система формирования отчетов должна как-то задействовать подобный вариант решения. В общем пока все по-прежнему... не разбирался