Is there any way to see exact results of an executed update statement in SQL Developer instead of only number of rows updated? Of course before commiting the statement. I'd like to see what changes were made to rows affected by statement and which rows were affected, but I couldn't find a way to do it.
I dont think theres a way to get exactly what you want, ie, to see the exact results of an update statement.
Its almost always a good idea to run a select query with the same conditions in your WHERE clause of your update or delete statements to see the records that would be affected before running any non-trivial update or delete statements.
You could also use the SQL History tab (View (in the menu bar) -> SQL History or press F8) to see all the SQL thats been executed in the past. This works on Oracle SQL Developer version 3.1.xx
Related
Is there (simple) way in a CDatabase (against an MDB file), after BeginTrans, to check how many records will be affected by an ExecuteSQL call that does a DELETE, INSERT, UPDATE or ALTER? In CDaoDatabase there is GetRecordsAffected - but I can't find anything similar for CDatabase.
I was (previously) using the number of affected records as a level of confirmation that my SQL was doing what I intended before either committing or rolling back the transaction. However I haven't been able to replicate that functionality since changing DB API tech.
I could probably auto-formulate a SELECT statement with the same WHERE parameters and count the results - but that is a lot of work, and I was hoping I missing something simple...
I am sorry in advance if I sound noob. I am looking through code for stored procedure and I came across:
select
...
into
....
from
....
where
....
for update;
I don't understand what is the purpose of for update;.
I do understand normal update, similar to: http://www.mkyong.com/oracle/oracle-stored-procedure-update-example/. But not able to get my head around for update; and its purpose.
I looked around but could not find clear explanation.
From the document:
The SELECT FOR UPDATE statement allows you to lock the records in the
cursor result set. You are not required to make changes to the records
in order to use this statement. The record locks are released when the
next commit or rollback statement is issued.
Also refer the Oracle docs which says:
The FOR UPDATE clause lets you lock the selected rows so that other
users cannot lock or update the rows until you end your transaction.
You can specify this clause only in a top-level SELECT statement, not
in subqueries.
So the purpose is quite clear it is used when you want to lock your rows during a transaction so that it cannot be used by some other transaction.
You can also refer: FOR UPDATE Clause in a SELECT Statement to get an idea as to how we can use it.
I have a sql statement that first updates, then selects:
UPDATE myTable
SET field1=#someValue
WHERE field2=#someValue2
SELECT 1 returnValue
The process that consumes the reults of this statement is expecting a single result set, simple enough.
The problem arises because an update trigger was added to the table that produces a result set, i.e. it selects like so:
SELECT t_field1, t_field2, t_field3 FROM t_table
The obvious solution is to split up the statments. Unfortunatley, the real world implementation of this is complex and to be avoided if possible. The trigger is also nessecary and cannot be disabled.
Is there a way to supress the results from the update, returning only the value from the select statement?
The ability to return result sets from triggers is deprecated in SQL Server 2012 and will be removed in a future version (maybe even in SQL Server 2016, but probably in the next version). Change your trigger to return the data in some other way. If it is needed just for debugging, use PRINT instead of SELECT. If it is needed for some other reasons, insert the data into a temporary table and perform the SELECT from the calling procedure (only when needed).
I'm using SQL Server 2012, and I'm debugging a store procedure that do some INSERT INTO #temporal table SELECT.
There is any way to view the data selected in the command (the subquery of the insert into?)
There is any way to view the data inserted and/or the temporal table where the insert maked the changes?
It doesn't matter if is the total rows, not one by one
UPDATE:
Requirements from AT Compliance and Company Policy requires that any modification can be done in the process of test and it's probable this will be managed by another team. There is any way to avoid any change on the script?
The main idea is that the AT user check in their workdesktop the outputs, copy and paste them, without make any change on environment or product.
Thanks and kind regards.
If I understand your question correctly, then take a look at the OUTPUT clause:
Returns information from, or expressions based on, each row affected
by an INSERT, UPDATE, DELETE, or MERGE statement. These results can be
returned to the processing application for use in such things as
confirmation messages, archiving, and other such application
requirements.
For instance:
INSERT INTO #temporaltable
OUTPUT inserted.*
SELECT *
FROM ...
Will give you all the rows from the INSERT statement that was inserted into the temporal table, which were selected from the other table.
Is there any reason you can't just do this: SELECT * FROM #temporal? (And debug it in SQL Server Management Studio, passing in the same parameters your application is passing in).
It's a quick and dirty way of doing it, but one reason you might want to do it this way over the other (cleaner/better) answer, is that you get a bit more control here. And, if you're in a situation where you have multiple inserts to your temp table (hopefully you aren't), you can just do a single select to see all of the inserted rows at once.
I would still probably do it the other way though (now I know about it).
I know of no way to do this without changing the script. Howeer, for the future, you should never write a complex strored proc or script without a debug parameter that allows you to put in the data tests you will want. Make it the last parameter with a default value of 0 and you won't even have to change your current code that calls the proc.
Then you can add statements like the below everywhere you will want to check intermediate results. Further in debug mode you might always rollback any transactions so that a bug will not affect the data.
IF #debug = 1
BEGIN
SELECT * FROM #temp
END
I am trying to update a row on an SQL SERVER 2005. When I run the SQL, I receive a message indicating that the Execution was successful and 1 row was affected. However, when I do a select against this row I supposedly updated, the value remains unchanged. What's going on with this SQL server when a successful query does absolutely nothing.
The query is:
UPDATE [database1].[dbo].[table1]
SET [order] = 215
WHERE [email] = 'email#email.com'
check for a trigger on [database1].[dbo].[table1], possibly it is doing something you are not aware of.
EDIT
without seeing the trigger code, you probably just need to add support for [order] into the trigger, since it is a new column (based on your comment).
Thanks KM I checked the triggers and you were right. There was a trigger that I had to disable to get the sql to work.