04-28-2023 02:07 PM
Is there a way, in a member formula or Finance BR, to write annotation data back to the database in bulk?
In OneStream rule writing, it's best practice to limit the number of times you are writing data back to the database (ideally only one SetDataBuffer at the end of your code). However, it does not appear that you can include annotation information in the DataBufferCell objects that are used in a data buffer.
Is there an alternate way to be able to set a large quantity of intersections at one time (like a SetDataBuffer), but for Annotation information instead of values?
04-28-2023 04:28 PM
Hi Phil,
Onestream in the backend does not store any alphabetical value it only keeps number in the backend table for cube data.
What you can do is create a DBCL in that append all the intersection info and the annotation value to a dictionary and with that dictionary create a table in the backend and store that info there and when you want to access that information you can cache in that table as a dictionary and look for that value you want to refer using the intersection as key.
This will help you to store the information in bulk using a DBCL but to a custom table.
04-28-2023 05:12 PM
Hi Omkareshwar,
I'm not actually looking for anything custom. I'm talking about OneStream's standard annotation functionality (i.e. - V#Annotation). I want to populate the V#Annotation members in a data buffer in much the same way you would populate the numeric values in a data buffer.
Thanks,
04-29-2023 02:36 PM
How about a Form Import Template? There is a Marketplace solution (IMT - Import Template Forms) in which there are various Token driven forms such as this:
Then go to your Cube settings where you are looking to load this data:
Then create a data source to ensure Excel loads are enabled:
Or create an import template with tokens as shown in below screen shot and load through a base import workflow profile type
Search in Design and Reference guide for more on Tokens:
04-29-2023 03:32 PM
You could save it to the annotation tables. However, loading a lot of values to the annotation table and using it back to do calculation logic is a bad idea. It can be a performance hog in most cases. You might have to take a different approach if this is intended to drive calculations.
06-14-2023 03:12 PM
We've used the the api.Data.SetDataAttachmentText function to set the data attachments in the past. This function uses a member script to set the value in the dataattachments table which is where the annotation type data is stored. Specifically we've used this function executed from a custom calculate script to copy annontations from one scenario to another.
The attachment type is the field in this table that identifies which view member that the information is stored in; it's stored as numeric value there but the values and how they relate to the actual view members are as follows:
200 = Annotation
220 = Assumptions
221 = AuditComment
222 = Footnote
223 = VarianceExplanation
If you can generate the member script and text while in your loop - you may use this function to set the value text in the loop and the value at the end.
07-08-2023 05:53 AM
Yeah this is the way to go. Have you had to copy over data attachments that are actually files and not text? If yes, how did you approach it?
07-11-2023 11:42 AM
You know I haven't had a need to do that yet - but would be interested to hear other's ideas.