Reporting from vDataRecordAll view
Hi everyone,
I don't find a lot of documentation about the vDataRecordAll view. Is there a reason as to why this is not easily available?
How hard is to get the JOINS to the main tables, so we ca...
Forum Discussion
Hi FrankDK / NicolasArgente
Thanks for the feedback.
I also agree with that statement 🙂 I also know the content of the view, I was interested in getting the dimension members aligned with the IDs i see in there.
I am having some performance issues while doing allocations. I get the result, but its just far too many combinations - we are trying to drop some of the details with the client.
So I thought of bringing the data from Cube to Table (in this case i would access the source data from the table) and apply the logic with an output in a different table. As I would believe that this could run a bit quicker (done a ton of times in the past) 🙂 currently it is taking 10hrs for 12 periods, 10k+ entities. I have a breakdown by Accounts (few thousands), and Cost Centre (another few thousands).
Cheers
Hi Raf: are you using databuffers for your calculations? If not, start there. Also, do you truly mean 10k+ entities? That could imply tens of billions of unique intersections depending on the density of the data (10000 [entities] * 2000 [accounts] * 2000 [cost centers]). I would love to understand more what you're working towards; even if just to satisfy my curiosity around 'the cool things possible in OneStream'
I am using Data Buffers and the calculation is huge - it finished after 11 hr running, and it generated 71 mi rows.
This is a Cost Centre transfer based on %.
Ex:
CC1 as Source goes to (Target) CC2 - 50%, and CC3 - 25%, and CC4 - 25%.
This is based on Entities, CC, and Account.