Возникла необходимость изменять значения Признаков в формате планирования BPS, что стандартно не предусмотрено.
Для этого воспользовались функциональными модулями: API_SEMBPS_GETDATA, API_SEMBPS_SETDATA, API_SEMBPS_POST.
В результате чего, все данные вначале скопировались из транзакционного куба в таблицу для ввода данных, мы изменили некое значение Признака, затем данные передались в буфер и снова в транзакционный куб. Все хорошо, только единственное но. При изменении значения Признака, запись дублируется. Т.е., например, мы изменяли значение признака «Улица» с ул. Северная 45 на ул. Комсомольская 67, в результате в формате планирование вышло следующее:

Месяц поставки Улица ….

06 ул. Северная 45
06 ул. Комсомольская 67

Вопрос: Может, кто подскажет каким функциональным модулем еще можно воспользоваться, чтобы полностью удалить строку в формате планирования со старым значением измененного Признака?

Всем большое спасибо за ответы.

А в кубе при этом надо оставить старые данные или нет? Если нет - может удалять их просто?

Да, в кубе старые данные не нужны.

Тогда параллельно вопрос, если в формате планирования целую строку со старыми значениями признака удалить автоматически не возможно, а в ручную отслеживать и удалять ненужные строки со старыми значениями признаков не подходит. Может можно все таки воспользоваться каким - то функциональным модулем для удаления данных.

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

Только не знаю название такого функционального модуля, который бы удалял целую строку со старыми значниями признака. Может кто подскажет?

Прелагаю на FOXe формулой просто обнулять.
Для этого надо написать формулу потом всё функции включить в глобальную последовательноссть.

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

Ещё можно с какой-нибудь периодичностью делать сжатие...

А вообще, для таких целей, как ведение комментариев в форматах планирования, мне пришлось написать USER-EXIT, который записывал данные в признак с соединением. В общем, сложно нормально объяснить, так как способ очень извращенный... Если все ещё актуально, то попытаюсь расписать поподробнее. В общем, в конечном итоге и комментарии велись, и на признаке висели, и в отчетах видны были, и менять их можно было без проблемм без всяких там API_SEMBPS_GETDATA.

А может быть, имеет смысл восользоваться функцией UPC_CHA_VALUES_UPDATE (или что-то подобное) и ничего не удалять?

Тут нужно посмотреть что происходит в кубе, когда ты делаешь SETDATA:



Единственное, что я не уверен в поведении записи 2, возможно BPS умеет обрабатывать такую ситуацию, но это не суть.

Исходя из вышеописанного остается три варианта:
1. Подавлять нули (или смириться с их присутствием).
2. Чистить куб (ФМ можно поискать по форумам) - считаю порочной практикой.
3. Обновлять тексты улиц (например клиент 001 был адрес ул. Северная 45 стал ул. Комсомольская 67).

Высказался

----

Во-первых для выборочного удаления существует транзакция delete_facts.

Функциональный модуль, который непосредственно осуществляет удаление: RSDRD_SEL_DELETION

Разобраться какие параметры надо использовать в данном ФМ вполне реально.

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

Мы на проекте еще использовали следующий "трюк": делали полную копию куба, затем одним пакетом "перекачивали" данные в back-up куб, а затем назад. Количество записей существенно уменьшалось. (Только не спрашивайте зачем мы это делали... )