Write-Back Limitations

Users can write back to any data source that allows the execution of SQL queries from Oracle Analytics .

As you configure for write back, keep the following limitations in mind:

  • Numeric columns must contain numbers only. They mustn't contain any data formatting characters such as dollar signs ($), pound signs or hash signs (#), percent signs (%), and so on.

  • Text columns must contain string data only.

  • If a logged-on user is already viewing a dashboard that contains an analysis where data has been modified using write back, the data isn't automatically refreshed in the dashboard. To see the updated data, the user must manually refresh the dashboard.

  • You can use the template mechanism only with table views and only for single-value data. The template mechanism isn't supported for pivot table views or any other type of view, for multiple-value data, or for drop down columns with single-value data.

  • All values in write-back columns are editable. When displayed in non printer friendly context, editable fields are displayed as if the user has the Write Back to Database privilege. However, when a logical column is mapped to a physical column that can change, the logical column returns values for multiple level intersections. This scenario might cause problems.

  • Any field in an analysis can be flagged as a write-back field, even if it's not derived from the write-back table that you created. However you can't successfully run the write-back operation if the table isn't write-back enabled. The responsibility for correctly tagging fields lies with the content designer.

  • A template can contain SQL statements other than insert and update. The write-back function passes these statements to the database. However, Oracle doesn't support or recommend the use of any statements other than insert or update.

  • Oracle Analytics performs only minimal validation of data input. If the field is numeric and the user enters text data, then Oracle Analytics detects that and prevents the invalid data from going to the database. However, it doesn't detect other forms of invalid data input (values out of range, mixed text and numeric, and so on). When the user clicks the write-back button and an insert or update is run, invalid data results in an error message from the database. The user can then correct the faulty input. Content designers can include text in the write-back analysis to aid the user, for example, "Entering mixed alphanumeric values into a numeric data field isn't allowed."

  • The template mechanism isn't suitable for entering arbitrary new records. In other words, don't use it as a data input tool.

  • When creating a table for write back, ensure that at least one column doesn't include write-back capability but does include values that are unique for each row and are non-null.

  • Write-back analyses don't support drill-down. Because drilling down modifies the table structure, the write-back template doesn't work.

    Caution:

    The template mechanism takes user input and writes it directly to the database. The security of the physical database is your own responsibility. For optimum security, store write-back database tables in a unique database instance.