This content has been marked as final. Show 3 replies
Can you ellaborate on why you want to do this? What are you looking to achieve?
I was thinking importing CELL TEXTS from Database when running the integration script. Then we add the cell texts from another script.
In any case, I realized Any dimension, attribute or description columns are limited to 70-75 characters...20 in case of attributes
I assume importing them into Description would be better than any other extra dimension but this is not valid if we have CELL TEXTS longer than 70 characters...
Is there any way of importing cell texts during import stage?
By the way, I cannot find any doc where differences between dimension properties are stated:
Long story short, out of the box you could re-use existing columns in the databases or other fields perhaps; however, if you've already looked at that and nothing works how you want it, your options are going to require customization.....
Doing this would be pretty straight forward, although you might incur minor wrath from Oracle support depending on how you implement it. Basically you'd need to do a couple things that come to mind ......
#1 - Create a data storage area
#2 - Recognize the data on the import
#3 - Store the data in the storage area
#4 - Make a retrieval mechanism for this info (Why would you store it if you can't ever view it?)
For #1 - Assuming you can't make use of any of the existing database columns (I think you could...) I would just add another table in the FDM database that will contain the info you want. Considering we're talking about loading data, you'd probably want to add a foreign key and create a relationship with the relevant existing tables/columns such as tDataSegxx (Columns DataKey or PartitionKey/CatKey/PeriodKey). I'd also make sure that I enable referential integrity and have the actions be to remove/update data so that you don't orphan data in this new table at a later date.
For #2 - Update your import format to have another column which will be your text and then I guess you have some choices. For the column you could instruct it to execute a script and just have that do the work to put the data into a database column; however.... I'd probably handle this in the AftValidate as at that point you should have all the info you need to get at the relationship data you would want. Bottom line is that there are options to this.
For #3 - Similar to point #2, there are plenty of options for how to store this. Assuming you are storing in a separate table and not repurposing an existing database column in FDM, I would just use ADO via scripting to do the inserts/updates/deletes.
For #4 - Not sure what you want to do with this information, but you should be able to get to it with an FDM report, or you could get to it on the export stage via script, etc, etc.