Добрый день!
Есть необходимость считать в переменную над 0calday
значение (дату) последнего изменения данных. Ту самую, что в текстовых элементах, добавляемых в рабочую книжку, обозначается как "время изменения" (changed at)
Есть ли стандартные фм для этого, или мб кто-то уже сталкивался с задачкой?

Мне кажется что этот параметр отображает время внесения последних изменений в Bex-запрос, но не в данные.

Лен, деривируйте дату в куб из текущей и заполняйте значение из преквери или прямым запросом к таблице измерений (зависит от задачи).
А бекс берет данные из запросов куба с зеленым и желтым статусом. Как не знаю.

Air_demon, именно дату последних изменений данных. Какой смысл для запроса держать два значения "с" и "по"?

Я имел в виду, что "время изменения" показывает, когда последний раз сохранялся запрос в QD.

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

Сделать текстовый элемент со временем последнего изменения. Это подходит?

Если вдруг не устраивает стандартный текстовый элемент в Analyzer'е, то можно поискать даты в запросах по табличкам RSICCONT и RSMONICDP.

Текстовый элемент "время изменения" не подходит, так как показывает время изменения запроса в qd, а не время последнего сохранения данных (данных в опред.разрезе).
Метка времени и пользователь заполняются деривацией.
Но я все равно не понимаю, как вывести в рабочуб книгу инф. о времени последнего сохранения данных.
Если можно, распишите поподробнее как и с какой целью обращаться к таблицам. Я с полуслова не понимаю-)

При открытии любого запроса на стандартном шаблоне есть под заголовком во второй строке текстовый элемент "Актуальность данных", я так понял о нём тут речь?
Эта дата и время берётся из последнего загруженного запроса ППД(DTPR), но с какого шага не понятно, всегда по разному почему-то.
Если Bex-запрос построен на мультипровайдере, то отображается самая ранняя дата из последних загруженных запросов ППД всех кубов мультипровайдера.

В bex запросах готовых к вводу, берётся дата из APO запросов.

Интуитивно и опытным путем установоено, что актуальность данных - это дата и время открытия книжки, а не сохранения данных. Т.е. Если открыть и обновить книжку, то актуальность данных показывает время обновления книги. Если при этом сохранить данные в книге, то значение актуальности данных не изменится. Видимо потому, что последние сохраненные данные оказались в запросе АРО, который по каким-то причинам (например, до поры до времени обретается в желтом статусе), в актуальность данных не попадает.

Задачка состоит в том, чтобы отображать дату изменения, меняющуюся синхронно с сохранением данных

Просто есть разница между готовыми к вводу и не готовыми.
Открытие готовых к вводу запросов и обновление переменных актуальную дату меняют на текущую. (Но это не дата APO запроса, как выяснилось)
А не готового к вводу, тоже берётся не понятно от куда. Перечисленные ash таблицы не содержат даты, которая отображается в Актуальной дате.
В жёлтом статусе APO тоже отображаются в табличках ash.. (Timestamp там в GMT)
Сейчас для эксперимента в запросе готовом к вводу на уровне агрегации, сохранил данные, и обновил рабочую книгу. Но дата в APO не изменилась, соответственно и табличках этих она не изменилась. Она там меняется только когда новый APO запрос открывается. После открыл запрос не готовый к вводу на том же кубе. Стоит дата последнего сохранения данных, но не дата APO.
Значит как вариант можно использовать не готовые к вводу запросы на готовом к вводу кубе, чтобы увидеть в актуальной дате дату последнего сохранения.
Ещё вот эта тема поможет сделать деривацию, чтобы каждое сохранение записывало всю историю изменений. http://sapboard.ru/forum/viewtopic.php?f=12&t=15579

Задача решена коллегиально и обходным путем: с пом. тех. запроса, который выиаскивает метку времени (заполняется деривацией).
Возник еще один вопрос: значения метки времени в кубе и на рабочей книжке отличаюся на +4 часа. То есть если я сохраняю данные в 14.21, то в кубе метка времени заполняется равной 14.21, а в рабочей книжке она же отображается как 18.21. Как бороться с этим?

Ой, не стоило бы ссылаться на такую старую тему с решением для BPS.
Уже есть новая хаутушка для 7.0 и c 7.01 есть бадишка для записи данных в DSO.



Лена, нужно по месту смотреть . Я в STS эту фигню так и не поборол. Навскидку самый простой выход -- поменять деривацию, т.е. писать не локальную дату а дату по гринвичу. Тогда смещение на 4 часа приведет к нужному результату.

2Zabava - что у вас под метку времени, какой инфо-объект? если вы используете 0TCTTIMSTMP, то обратите внимание на
преобразование TIMS в определении.

это значит, что писать вы можете туда только метку в UTC часовом поясе, потому как при выводе на экран BW будет показывать вам метку с учетом вашего часового пояса.