Using Oracle 10g
Is it possible to get the value of a newly updated field within the same transaction before it is committed.
I am executing a stored procedure which calls 2 other stored procedures.
The first stored procedure gets a record from a table and then updates that record.
The second stored procedure gets that same record but needs to use the newly updated fields from the first stored procedure.
Then the commit is carried out.
The commit can only be done if both procedures are carried out sucessfully.
Will the second stored procedure get the newly updated data or will it get a copy of the same data that was returned in the first procedure without the update ?
Oracle has a very simple and robust implementation of read consistency:
a user sees the latest version of the data, including any changes made by the current transaction, but ...
a user cannot see the changes made by any other user until that other user issues a commit, and even then not until executing a new statement.
This is covered in the Concepts Guide. Find out more.
Related
I have a stored procedure and materialized view in same DB.The purpose of this procedure is to refresh the materialized view.
When I run the procedure directly from db mview is refreshed properly means the mview returns more data.
Now I done an informatica mapping ,this mapping call the store procedure to refresh the mview.
It runs properly but mview does not refresh properly that means the mview contains less data rather than first try.
My Question is that why the materialized view does not contain the all data after refreshing through informatica?
materialized view refresh type is complete.
Most likely the problem is that you've not invoked the stored procedure successfully at all but have convinced yourself that you have. Please include the excerpt of the session logs that confirms the stored procedure ran successfully (also check the connection used when the stored procedure call is made is the same as it should be i.e. you may have chosen a connection when writing the mapping but in the workflow it will be set to the default which most likely isnt the same)
I need some advice in how to handle the following:
Firebird 2.5 (I use Delphi XE2).
I have 2 structure identical database.
I have some triggers and SP on the table that I copy.
I copy 1-2-3 records from one table database to another.
trigger After Insert (execute one stored procedure that recompute some other records from the same table).
The database are identical but in one database the after insert work ok and in the other one no.
Also both trigger ARE working. (for testing purpose I raise an exception and is fire the exception).
So i want to find a way to track what is happening and to find the problem.
How to monitor/debug this situation.
also how to track deadlock?
any advice?
Check whether the not working trigger is active.
I have an Oracle trigger which is calling a stored procedure that has PRAGMA AUTONOMOUS_TRANSACTION defined. The values that are passed from the trigger have been committed already but it appears that the values are not available in the stored procedure? I'm not positive of this since the ability to debug/log/commit is difficult and the timing of the output is confusing me a bit. I'd like to know if it's expected that any passed values are simply available in the stored procedure regardless of the AUTONOMOUS_TRANSACTION?
Thanks
Values passed in to a stored procedure as parameters will always be available to the stored procedure. It doesn't matter whether the procedure is declared using an autonomous transaction.
Code running in an autonomous transaction cannot see changes made by the calling transaction. 9 times out of 10, when people are describing problems seeing the data they expect, this is the source of the problem.
If your stored procedure is doing anything other than writing something to a log table, I would be exceptionally cautious about using autonomous transactions. If you are using autonomous transactions for anything other than logging, you are almost certainly using them incorrectly. And you are probably introducing a whole host of bugs related to race conditions and transactional integrity.
"The trigger logic is conditionally
updating Table B which calls the
stored procedure to select from the
values on Table A so that Table B can
be updated with a calculated value. "
Perhaps Table B really ought to be a Materialized View derived from Table A? We can build a lot of complexity into the WHERE clauses of the queries which populate MViews. Find out more.
If you have a row level trigger on table_x, then that trigger can be fired multiple times by the same statement as different rows are impacted by that statement.
The order in which those rows are impacted is indeterminate. As such, the state of table_x is indeterminate during the execution of a row level trigger. This is why the MUTATING TABLE exception is raised.
An autonomous transaction 'cheats' by looking at the committed state of the table (ie excluding all changes made by that statement, and other statements in the transaction).
If you want a stored procedure to look at the state of table_x in response to activity on that table, then it needs to be done after all the rows changes have been made (ie in a statement level trigger, not a row level trigger).
The design pattern for this is often to set a flag (package level variable) in a row level trigger, check the flag in an AFTER statement level trigger, and if necessary action it and reset it.
I created the Employee table which contains EmpNo,EName,EDesignation as its fields.Also i created the 3 Triggers namely Trigger_1,Trigger_2 and Trigger_3.All the Triggers are Statement level triggers and fired after the update done in the table.Now i want the following orders in which the triggers are going to fired when the update statement is executed.
The Order is
Trigger_3,
Trigger_1,
Trigger_2
Can anyone tell me the way to fire the trigger events in userdefined way?I m using Oracle 9i
Trigger Evaluation Order
Quote from Oracle documentation:
Although any trigger can run a
sequence of operations either in-line
or by calling procedures, using
multiple triggers of the same type
enhances database administration by
permitting the modular installation of
applications that have triggers on the
same tables.
Oracle Database executes all triggers
of the same type before executing
triggers of a different type. If you
have multiple triggers of the same
type on a single table, then Oracle
Database chooses an arbitrary order to
execute these triggers.
Each subsequent trigger sees the
changes made by the previously fired
triggers. Each trigger can see the old
and new values. The old values are the
original values, and the new values
are the current values, as set by the
most recently fired UPDATE or INSERT
trigger.
To ensure that multiple triggered
actions occur in a specific order, you
must consolidate these actions into a
single trigger (for example, by having
the trigger call a series of
procedures).
see also http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14251/adfns_triggers.htm
Have one trigger with the contents of the three.
If you cannot, for reasons for modularization, reusability..., create three stored procedures and call these one by one in the single trigger.
Upgrade to 11g and you can define trigger execution order
Suppose I'm using the following Oracle code in a stored procedure:
CREATE GLOBAL TEMPORARY TABLE temp_table (
field1 NUMBER,
field2 NUMBER
)
ON COMMIT DELETE ROWS
This particular stored procedure may be called concurrently by different users at any single moment. As I understand it, the data visible to the user in the temporary table will be private to him or her, and these rows are deleted on a COMMIT.
However, how do the following work with respect to this:
Is it safe to call the CREATE statement above every single time the stored procedure is called? Would this result in an error cause there already "exists" a temporary table (possibly) created by a different user (/session)? Or would this be OK, since the server treats them privately anyway?
What exactly happens with the ON COMMIT DELETE ROWS? I assume that this only deletes the rows specific to the particular user session, leaving the data by other sessions unharmed, correct?
Any help would be appreciated. :)
Q1: Is it safe to call the
CREATE statement above every single
time the stored procedure is called?
The main reason you create a global temporary table (GTT) is to create once (not inside procedure) and use it as private table for a session. It will throw an error if the table already exist.
Q2: What exactly happens with the ON COMMIT DELETE ROWS?
Yes. The data gets deleted once you commit. This happens only for the session you operate.
Check creating GTT and its use.
I'd just leave the table there. No sense in dropping and recreating it all the time. It will cause concurency issues as you say.
Yes.