Last Updated on Monday, 19 November 2012
We have a report in SQL Server Reporting Services 2008 R2 (SSRS) reading from an Oracle 10g database which works great and lists all the details on a specific student. An additional request is that there appears a link that will run a stored procedure which
- Updates a timestamp in an existing table
- Inserts a row into an audit table
We use a database account with read-only privileges to list all the details. On the last report, the one to execute the stored procedure, we use an account specifically created to run the stored procedure. This requires using 2 data sources in SSRS.
- A user will specify the student reference in the parameters of the first report (the one with all the main details), as well as a job reference (for audit purposes) and click "View Report".
- The report will refresh with a link to a confirmation report which the user clicks and confirms that this is the student to update.
- The confirm button links to a 3rd report which will actually execute the stored procedure which updates the student record as well as an audit table.
The last report will execute the stored procedure without any problems. I added a second dataset on this report to select the updated data that this stored procedure commits but unfortunately SSRS process both the Stored Procedure and the SELECT at the same time; this meant the report would say the process failed but when I check the logs, it successfully ran the stored procedure (updating both tables).
I want to avoid the workaround, because so far my workaround is a fourth report which will do the select to check that the update happened. Unfortunately this means that when the report was executed, it could only really display a message saying "executed stored procedure", "please click on the link to continue" and then the user would be taken to a report which says either "Stored Procedure was successful" or "No sorry you're going to have to go back to the beginning and try that again."... This isn't a solution that sounded good enough for our customers.
The Workaround we actually went with
Our Stored Procedure would check if the unique identifying number (in our case StudentID) matches a record in the database table and that the request number was alphanumeric. In addition, this would be checked at the database level, and returned in a dataset for SSRS to complete the check. Instead of outputting the error code to our end-users, we decided to store the error code in the audit table and that in the eventuality of an error happening, the end-user would contact us and we would look up this error code.
Instructions on setting up an Oracle Stored Procedure
I already wrote an article on this so please refer to SSRS Parameters in Oracle Stored Procedure.
Oracle: Grant another user permissions
- /* on the table: ssrs_audit_table */
- CREATE OR REPLACE PUBLIC SYNONYM ssrs_audit_table FOR base_table_owner.audit_table;
- GRANT SELECT, UPDATE, INSERT ON ssrs_audit_table TO ssrs_sp_user;
- /* on the SP: ssrs_stored_procedure */
- CREATE OR REPLACE PUBLIC SYNONYM ssrs_stored_procedure FOR base_table_owner.ssrs_stored_procedure;
- GRANT EXECUTE ON ssrs_stored_procedure TO ssrs_sp_user;
- -- where ssrs_audit_table is a table that we want to use as an audit table
- -- where ssrs_stored_procedure is a stored procedure we made
- -- where ssrs_sp_user is the user to run the stored procedure in SSRS
- -- where base_table_owner is your base table owner
Searches that got me nowhere
- ssrs stored procedure successful or not
- Fri 06-Dec-13
- Mon 25-Nov-13
- Wed 04-Dec-13
- Tue 03-Dec-13
- Tue 03-Dec-13