Не пробовал, просто интересно стало, можно ли транзакционный куб закачивать, как базовый, т.е. пристёгивать к нему всю цепочку прохождения данных, и не повлияет ли это на ввод данных в куб в транзакциях BPS, например ?

Переключаешь в загрузку - загружаешь
Переключаешь в планивание - планируешь в BPS

Все верно сказал Maximus.
Остается добавить, что одновременно вводить данные вручную и загружать данные нельзя.

Более того - можно сделать цепочку

переключить в режим загрузки
заргузить
переключить в режим планирования

смотри FM RSAPO_SWITCH_TRANS_TO_BATCH - переключение в режим загрузки
RSAPO_SWITCH_BATCH_TO_TRANS - обратно.

А можно сделать два куба. Один для ввода, другой для загрузки. А над ними - мультикуб.
Тогда вообще ничего переключать не надо.

И биться они не будут, когда пойдет дублирование записей...

А зачем плану и факту биться?

Хе хе.
Они в обоих случаях "биться" не будут, если пойдет дублирование.
Данные-то удаляются/заменяются пакетами по критериям выборки.
Вывод - надо избегать дублирования. Например, вводить план, а загружать факт.

Во первых ничего там не "удаляется/ заменяется пакетами по критериям выборки" . Это полная околонаучная чушь. Такого понятия как "замена/удаление по критериям выборки" в транзакционнм кубе вообще нет. Рекомендую для начало просто почитать документацию. Потом сесть и самому ручками хотя бы раз проделать то, что Вы говорите. И посмотреть результат. А потом разобраться как работает BPS и что он пишет в куб при изменении данных. И после этого всякий бред по поводу "замены/удаления да еще по критериям выборки" отпадут.

Во вторых, надо прежде всего думать головой перед тем, как проектировать систему.

А в третьих - грузите себе спокойно. если знаете что делаете.

В данном случае есть только одна засада. После загрузки даных в куб при проеведении планирования могут быть загруженные данные изменены в ручную. Тогда весьма пробелматично будет откатить загруженные данные .

Хинт. Если немного подумать и почитать, тогда понятно будет,почему после загрузки данных и изменения их в bps нельзя будет ни удалить загруженный запрос, ни сторнировать.... Во всяком случае гемморой я вам гарантирую...

Второй хинт: транзакционный куб в режиме загрузки - это обычный куб со всеми вытекающими отсюдова последствиями

Третий хинт: пока сам не попробуешь и не увидешь результаты удаление/изменение/ввода новых записей в BPS с помощью хотя бы тразакции listcube - разговор просто бесполезен

Извините за резкость. Но действиельно бредовые формулировки и слова...

Удачи в борьбе с транзакционными кубами и bps.

2 BW-шник
Чего????
Все сказанное мной верно, за исключением того, что саповский термин "запрос" (Request) был заменен текущим бизнесОвым словом "Пакет".
То, что данные в любом инфокубе, транзационный он или базовый, удаляются request-ами вызывает сомнения?
Если есть сомнения, я тебе на пальцах объсню, и в документацию тыкну. Только для начала тон смени.



Сам-то понял, что написал? Я - нет

Значит так. При загрузке удаление проихводится ТОЛЬКО при соответствующей настройке в инфопакете. Надеюсь это то понятно? Или все таки и с этим спорить будем?

А во вторых - я извинился за резкость. В конце. А если ты не понимаешь отличия транзакционнго куба - то это не моя вина. Объясняю для непонятливых:

в bps вводим данные
переключаем куб
загружаем
переключаем обратно
теперь заходим в bps и видим не только ввденные данные но и загруженные
изменяем загруженные данные и вводим новые в рамках одного открытого пакета.

А теперь попробуй вернуться к первоначальному состоянию до загрузки. Без геммороя не откатишь

Теперь понятно? если нет - то тогда - только рукми проделать то же самое и посмотреть.

Еще раз, Максим, если не знаешь предмета - не стоит рассуждать и показывать свое незнание да еще и обижаться на это. За тон - прошу прощения. За суть - готов драться за каждое слово.

ГЫ ГЫ ГЫ.
Я плакалЪ
А теперь объясняю я.

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

С точки зрения системы загрузки BW, то что формирует BPS - это такой же request, как и загруженные данные.
И прибить его можно. И из инфо-пакета в том числе. Там есть такая волшебная настройка в закладке "Цели данных" - "Автоудаление данных". Переключаете куб в режим загрузки и вставляете туда программу выборки запросов на удаление. Есть тонкости, но это отдельная тема.



Элементарно, Ватсон. Это как раз просто. Закрываем открытый пакет и грохаем его в администрировании инфокуба (или программно). Грохаем загруженный пакет. Всё! Имеем данные до загрузки.

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

И не надо меня "уличать" в "незнании предмета", BW-шник - это ты не знаешь предмета. Я такими фокусами занимаюсь не первый год, и на этом собаку съел.
И еще раз повторяю - смени тон. Это тон воинствующего ламера

Я тоже плакалЪ

Я не пытаюсь никого уличать. Это дело следователей

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

Про тон - я уже писал. Ничего личного. Спиши на последствие после тяжелой командировки.

Теперь по сути - насчет геммороя

Мало того, что после сторнирования запроса загрузки в кубе останется дельта из BPS - запроса, который пойдет следом за загрузкой. Гроханьем этого запроса BPS ты начисто убиваешь не только то, что относится к изменениям загрузки - то есть откат на момент загрузки данных, но и то что было введено новое пользователями. А теперь прикинь, что у тебя таких - человек 200. И все колотят и плодят данные. И попробуй теперь им объяснитть, почему пропали их данные.

Гемморой здесь в том, что ты не можешь удалить реквест частично.

А теперь усложним задачу. Так как у тебя 200 человек постоянно изменяют данные, причем объем ввода и изменений данных большой, то с целью ускорения работы BPS производится сжатие куба с подавлением нулей. И еще ты не знаешь, а изменили ли загруженные данные пользователи в ручную. А так же в качетсве "изюминки" - ты не знаешь, а использованы ли загруженные данные в дальнейшем планировании - то есть были ли порождены новые данные на основании загруженных - ну произведены какие нибудь расчеты и т.д.

А теперь в этих условиях ты не сможешь ни удалить реквест, ни применить выборочное удаление из куба. Выход - разбираться с каждым пользователем индивидуально и в ручную в BPS выкашивать данные - либо через прямое измение либо писать функции...

Вот именно об этом я говорил. Если не смог объянисть - извини. Если есть еще вопросы - готов разъяснить свою позицию.

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

Удачи.

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

А никто и не бушует Кубы пока в помойку не летят, хотя предложение сжать инфокуб с подавлением нулей уже поступило

2 ZZZ
Зачем же делать из частных примеров далеко идущие выводы?
BW-шник много хороших примеров привел того, как не надо делать. Не наступайте на известные грабли, и все у вас будет шоколадно.