SELECT - INSERT/UPDATE statement mapping.

This might be a silly question, but are there any Java libraries that can perform an arbitrary SELECT statement to INSERT/UPDATE statement mapping? Or indeed, is this in fact possible?
Just to be a little clearer, if we had the statement;
SELECT [Field1] FROM [Table1]
It would map down to;
INSERT INTO [Table1] VALUES [Field1]='foo'
Please excuse my INSERT syntax if it is incorrect, I hardly ever use these statements.
The reason that I ask is because I am writing a piece of software that can perform quite complex extractions from databases, and it would be nice to be able to automatically 'reverse' the extraction, and perform updates on the extracted data.
Unfortunately, because of the architecture and requirements of the application, I can not just update a resultset and call the update() method.
Thanks for your time.
Ben

You can define a Bean or simple class to define a table record type (table structure), defining all fields, the primary key and maybe more.
then deriving a select or insert or update can be done with ease.

Similar Messages

New Feature: Generate Statements (select, insert, update)

I finally moved to ubuntu, so no more toad for me. It will be nice if sql developer could have the generate statements menu ( select, insert update) found in Toad. This should be extremely simple to do. In my case it actually save me time when testing and creating store procedures.
Maybe the feature is there and I just dont know where it is.
Thank you.

There's an existing request for this on the Exchange; vote on that one to add weight, to increase chances of implementation.
Uncontaminated? How can you say that if you don't know what it's like being contaminated? You'd wish you were ;-)
Although I really like sqldev, the numerous bugs and performance issues I hit every day still force me now and then to use the much more mature Toad. At least I'm sure it does what I want it to do and that it won't screw up our production environment.
K.

Can I use a select and update statement in a single jsp file?

I want to update the BUY table everytime I would add a SELL transaction.....I want to minus the stocks that I sold to those that Ive bought before.....
note: I used a seperate table in BUY and SELL transaction
After I Have added a transaction, I want to update the buy table. This is my problem, can I used both SELECT and UPDATE statement at the same time in a single jsp file for example like this:
select * from test, test1;
update test
set total_shares=total_shares-Stotal;
where stock_code=Scode AND name_broker=Sbroker;
Can i have both of these statements in the same jsp file in oder to update the buy table?
Or can anyone suggest how can process that update?THANKS!
--------------------

Can i have both of these statements in the same jsp file in oder to update the buy table?Yes. But wouldn't it have been easier just to try it?

Audit "SELECT FOR UPDATE" statement

Hi all
My database is 10.2.0.3 and I enabled audit_trail to DB value already.
My purpose I want to audit "SELECT FOR UPDATE" statement on the table and I tried to enable audit "SELECT" on the table that have many records in dba_audit_trail because "SELECT" statement that include in this audit and then I tried to enable audit "LOCK TABLE" on the table that doesn't have any records n dba_audit_trail.
So my question is How to enable audit for collecting only "SELECT FOR UPDATE" statement? or anyone have any idea for this.
Regards,
Hiko

taohiko wrote:
Hi all
My database is 10.2.0.3 and I enabled audit_trail to DB value already.
My purpose I want to audit "SELECT FOR UPDATE" statement on the table and I tried to enable audit "SELECT" on the table that have many records in dba_audit_trail because "SELECT" statement that include in this audit and then I tried to enable audit "LOCK TABLE" on the table that doesn't have any records n dba_audit_trail.
So my question is How to enable audit for collecting only "SELECT FOR UPDATE" statement? or anyone have any idea for this.
A consideration on top of the comments made by Justin:
You have an unfortunate version of the database for auditing: when you enable audit on 10.2.0.3 (or.2 or .1) the redo pattern changes - normally you will see a redo change vector for each row updated, but in these versions you will see two records, a "lock row" followed up "update row piece"; which means your volume of redo may increase significantly.
I wrote a note about it some time ago: http://jonathanlewis.wordpress.com/2011/05/27/audit-ouch/ and one of the comments includes the bug number ( 5166745 ), reporting fixed in 10.2.0.4 and 11.1.0.6
Regards
Jonathan Lewis
This is bug

Rogue implicit SELECT FOR UPDATE statement in forms 9i 9.0.4.0.19

all,
out of 200 production forms, one form occasionally and incorrectly "selects for update" an entire 3 million row table, during an update transaction. this creates 100+ archive logs.
we cannot repeat the event via testing. but the rogue select statement has been captured from SGA and is listed below. its plain to see that somehow the where clause is truncated to a W, and is then used as a table alias, resulting in the entire table being locked.
has anyone seen anything like this?
SELECT ROWID,DISTRIBUTION_PARTY,DISTRIBUTION_PARTY_NAME,CORRESPOND_SEQ_NUM,DISTRIBUTION_SEQ_NUM,VENDOR_NUM,DEPENDENT_SEQ_NUM,INTERNAL_ATTORNEY_USER_NAME,MAIL_LOC,ORIGINAL_FLAG
FROM CLAIM_DISTRIBUTION_DATA W
FOR UPDATE OF DISTRIBUTION_PARTY NOWAIT

Find out where this select statement is issued from first of all. Is it in your code or is it issued implicitely by Forms? Since it has rowid I assume it is an implicit Forms call.
Do you use on-update triggers any where in this form? on-lock?

Execution time difference between SELECT & UPDATE statement in JDBC Sender.

Hi Experts,
In my scenario, I have used the JDBC Sender Adapter with the SELECT and UPDATE statement.
Now the problem is in between the execution of Select and update statement, few more entries are coming in the same DB Table.
So result of this is updation take place for those entries which are not even picked up by the select statement.
Can we avoid this execution time difference between the SELECT & UPDATE statemet on JDBC Sender side???
Thanks & Regards
Jagesh

Hi
Use serializable option in additional parameters, now all new entries would also be updated.

JDBC adapter - update statement

I have come to the conclusion that there is no direct connection between the select and update statement of a sender JDBC adapter, in terms of commit scope.
According to SAP documentation:
"The UPDATE statement must alter exactly those data records that have been selected by the SELECT statement. You can ensure this is the case by using an identical WHERE clause. (See Processing Parameters, SQL Statement for Query, and SQL Statement for Update below)."
But my point is: if select statement retrieves e.g. 5 rows based on a where condition, then the update statement could find 6 rows to update, if a row was inserted a split second after the select, but before the update. Result : a row is lost...
I don't think the select statement puts a lock on the table(s) it accesses, and releases this lock after update has been committed. This would ensure integrity between select and update statement.
Can anybody confirm or deny this ?

Hi,
Have you seen the<b> Isolation level for Transaction handling</b> in the sender JDBC adapter?
Make the Isolation level as Serializable and repeatable Read and the db gets locked anbd until Update happens, no Insertion can occur in the Split Second!
http://help.sap.com/saphelp_nw04/helpdata/en/7e/5df96381ec72468a00815dd80f8b63/content.htm
Regards,
Bhavesh

When is SELECT FOR UPDATE used

DB version:10gR2
Since another thread of mine on this subject didn't go well, i am starting another thread.
When exactly is SELECT..FOR UPDATE statement used? With the exception of using SELECT...FOR UPDATE in CURSOR declaration, I've rarely seen SELECT ...FOR UPDATE being used explicitlyby PL/SQL gurus in our firm. Why didn't they use SELECT..FOR UPDATE(i mean a stand alone SELECT FOR UPDATE, <em>not as a part of Cursor</em>) to lock rows before UPDATE/DELETE/INSERT in their codes?
Edited by: M.Everett on Oct 20, 2008 12:00 PM
edited the initial post to let the users know that I am refering to a stand alone SELECT FOR UPDATE statement, not the part of a cursor

M.Everett wrote:
What i gather from various sources in the Internet:
1. SELECT FOR UPDATE is used mainly on CURSORs and very rarely used as a stand alone statement (if this is not the case you would have seen SELECT FOR UPDATE statements before every UPDATEs and DELETEs in PL/SQL codes)
2. Stand alone SELECT FOR UPDATEs are used mainly when dealing with CLOB, BLOB
Am i right in making these conclusions?1. This is probably a fair assumption.
2. Not really. SELECT FOR UPDATE is not a requirement when dealign with (C|B)LOBs.
SELECT FOR UPDATE allows an easy form of reference when you come to update rows in a cursor loop (although cursor loops should be rarely used), because rather than having to include a where condition on key columns you can just refer to the CURRENT ROW. Obviously, the main reason for using SFUs is the locking and this can become a requirement in some business environments where a user "picks up" a record to deal with and other users will then not see that record in their list or be able to select it for themselves.
;)

Insert/Update table via DBLink

I have a situation where the table that I want users to be able to maintain is owned by a different schema on a different database.
TABLE1 is owned by SCHEMA1 on DB1
select,insert,update,delete is granted to SCHEMA2 on DB1
DBLINK is a DBLink from SCHEMA3 on DB2 to SCHEMA2 on DB1
HTMLDB is running on SCHEMA3 on DB2
This setup is necessary because SCHEMA1 is the main data repository, SCHEMA2 has limited access to SCHEMA1 for security reasons, and SCHEMA3 is where HTMLDB is installed
i.e.
SCHEMA3@DB2 --> SCHEMA2@DB1 --> SCHEMA1.TABLE1@DB1
Whenever I try to use the wizards to create a standard Report/Form combo it fails when selecting the table for the Form - table TABLE1 is not in the select list because it's not owned by the schema assigned to the workspace.
So I created a temporary copy of the table in SCHEMA3 and used the wizard to create the Report/Form combo. This works fine.
I then dropped the table from SCHEMA3 and created a synonym pointing to SCHEMA1.TABLE1@DBLINK
The report still works fine but the Automated Row Fetch fails with the error
"ORA-06550: line 1, column 17: PL/SQL: ORA-00936: missing expression ORA-06550: line 1, column 9: PL/SQL: SQL Statement ignored
I presume this is because it's specifically looking for a table owned by SCHEMA3 when in fact it's a synonym.
Is there any way around this without recoding all the optimistic locking, insert, update and delete code?

Doh! After all that I answered my own question ... it's really simple.
Create a view in SCHEMA3 pointing to the table in SCHEMA1 and create the Report/Form based on the view
e.g. CREATE VIEW table1 AS SELECT * FROM schema1.table1@dblink;
(Where's the Delete Post option when you need it?! ;)

Inserted | updated | deleted | merged

Hello,
If a table has been set to update/insert and a row arrives with a matching column then the corresponding row in the target table is updated. In the job details window shouldnt it show a 1 under the updated section. My question really is, what does the merged tab indicate ?
Thanks

Hi,
As per my knowledge
If map runs in row based mode-- insert,update tabs are filled
If map runs in set based mode- merge will come
Row Based mode: In the pl/sql pkg generated by the map
insert and update operation will happen for each row
For insert/update option --First insert statement will run if the record exists then exception will come , then in the exception block update statment will be there and thee the record will be udpated..
For update/insert option -- First it tries to update the record.. if it doestnt find the record it raises an exception , in the exception block insert statment will be ther
that will insert the record..
In Set based Mode:
Instead of separate insert/update statements one merge stament will be there it will run...
So set based mode is faster than row based mode..
If any errors comes, then its difficult to find the source record causing the error in set based mode as it is in merge statment
but it is easy in row based as it will do insert/update for each record --- each record will be inserted in the audit tables.
Hope this will give u an idea
Than you

How to convert pl/sql block into single update statement

Dear all gurus,
I have pl/sql block mention below, Can I convert this pl/sql block to single update statement if possible?
If not how to optimize this block?
Pleaese suggest.
thanks in advance.
Vijay
DECLARE
CURSOR vt_mlr_cursor IS Select master_key, user4 from vt_mlr Where USER4 is not null;
USERFIELD VARCHAR2(100);
C1 VARCHAR2(3); /* this will return location of first space = 12 */
C2 VARCHAR2(3); /* this will return location of second space = 20 */
C3 VARCHAR2(3); /* this will return location of third space = 28 */
C4 VARCHAR2(3); /* this will return location of forth space = 35 */
Field1 VARCHAR2(40); /* this will return FTMYFLXA04W */
Field2 VARCHAR2(10); /* this will return VPI0043 */
Field3 VARCHAR2(10); /* this will return VCI0184 */
Field4 VARCHAR2(10); /* this will return 005 */
Field5 VARCHAR2(10); /* this will return 00001 */
Field_2_n_3 VARCHAR2(25);
key VARCHAR2(10);
BEGIN
FOR vt_mlr_record IN vt_mlr_cursor
LOOP
key := vt_mlr_record.master_key;
USERFIELD := vt_mlr_record.user4;
C1 := INSTR(vt_mlr_record.user4,' ',1,1); /* this will return location of first space = 12 */
C2 := INSTR(vt_mlr_record.user4,' ',1,2); /* this will return location of second space = 20 */
C3 := INSTR(vt_mlr_record.user4,' ',1,3); /* this will return location of third space = 28 */
C4 := INSTR(vt_mlr_record.user4,' ',1,4); /* this will return location of forth space = 35 */
Field1 := SUBSTR(vt_mlr_record.user4,1,C1-1); /* this will return FTMYFLXA04W */
Field2 := SUBSTR(vt_mlr_record.user4,C1+4,C2-C1-4); /* this will return VPI0043 */
Field3 := SUBSTR(vt_mlr_record.user4,C2+4,C3-C2-4); /* this will return VCI0184 */
Field4 := SUBSTR(vt_mlr_record.user4,C3+4,C4-C3-4); /* this will return 005 */
Field5 := SUBSTR(vt_mlr_record.user4,C4+4,LENGTH(vt_mlr_record.user4)-C4-3); /* this will return 00001 */
Field_2_n_3 := Field2 || '/' || Field3;
/*DBMS_OUTPUT.PUT_LINE ('Current key is: ' || vt_mlr_record.master_key);*/
UPDATE vt_mlr
SET
aggregator_clli = Field1,
aggregator_vpi_vci = Field_2_n_3,
aggregator_slot = Field4,
aggregator_port = Field5
WHERE
master_key = vt_mlr_record.master_key;
END LOOP;
END;
/

Hi Vijay,
Here's something to start with, you should be able to complete it.
First, combine your select and update statements:
update vt_mlr
   set aggregator_clli = field1
      ,aggregator_vpi_vci = field_2_n_3
      ,aggregator_slot = field4
      ,aggregator_port = field5
where user4 is not null;Then put these two
C1 := INSTR(vt_mlr_record.user4,' ',1,1);
Field1 := SUBSTR(vt_mlr_record.user4,1,C1-1);into
Field1 := SUBSTR(vt_mlr_record.user4,1,INSTR(vt_mlr_record.user4,' ',1,1) -1);And put it into the update statement, removing reference to record
(I have also removed default values for position and occurrence in instr function):
update vt_mlr
   set aggregator_clli = substr(user4, 1, instr(user4,' ') - 1)
      ,aggregator_vpi_vci = field_2_n_3
      ,aggregator_slot = field4
      ,aggregator_port = field5
where user4 is not null; I think you can do the rest from here ;-)
Regards
Peter

Does the sequence of Insert/Update matter?

Dear friends
I wanted to know whether there is any difference in results if I change the sequence of Insert/Update statements. For example, if I'm inserting / updating records in a table, normally I write my code as below
<code>
Begin
Insert Into Table Name(...)
Values(...);
Exception
When Dup_Val_On_Index Then
Update Table Name Set
Column_Name = Value;
When Others Then
Sqlerrm;
End;
</code>
Lets assume, if I change the order of statements as below:
<code>
Begin
Update Table Name Set
Column_Name = Value;
If Sql%NotFound Then
Begin
Insert Into Table Name(...)
Values(...);
End;
Exception
When Others Then
Sqlerrm;
End;
</code>
So does this change make any difference in net results?

Yes...till before today morning, it had no difference to me too, but today I was facing an insertion problem in a procedure in which insert statement had to go into when_dup_val exception part after first record and execute update statement. But surprisingly, it was going into when_dup_val only for 2nd record, i.e. 1st record was inserted as new record, then 2nd record had same primary key values, so when_dup_val caused to execute update statement, and lastly for 3rd record, having same primary key values, instead of executing update statement, insertion was going into when_others exception part and raising error ORA-01008.
After very detailed hit n trial, I just reversed the operations, took udpate statement before insert in my code and then all the things got right. Procedure is executing finely.
Although I've resolved the issue but I couldn't digest this change, thats why asking you peeps the operations behind.

JDBC Sender - Different number of records selected and updated.

Hi people,
We have a JDBC -> Abap proxy scenario. The JDBC sender is pooling an Oracle database to retrieve data from a table X, each 30 minutes. The select and update statements in jdbc sender are below
SELECT FIELD1, FIELD2, FIELD3 FROM MY_TABLE WHERE STATUS = 1
UPDATE MY_TABLE SET STATUS = 2 WHERE STATUS = 1
Sometimes the message sent to Abap proxy has, for example, 400 records. Looking at runtime workbench, message monitoring, for the same message there is a log like this
Channel SENDER_JDBC_CHANNEL: Query executed successfully. Start update
Channel SENDER_JDBC_CHANNEL: 510 row(s) updated successfully
Someone has already experienced something like this? How can I handle this to guarantee to update only those read records?
regards.
roberti

Hi All,
Even we are facing the same problem.
In our scenario, receiver is SAPR3. (IDOC)
Will this parameter serialization work in our case?
1. SELECT XBLNR, WERKS, MATNR, MDV01, BACKFLQUANT, STATUS, SAPTIMESTAMP, PITSTIMESTAMP, PMTIMESTAMP, BATCH FROM PMBPITS.PITS_UNITY WHERE STATUS = '01' and rownum<200 .
2. UPDATE PMBPITS.PITS_UNITY SET STATUS = '02' , SAPTIMESTAMP = sysdate WHERE STATUS = '01' and rownum<200 ( currently the value is rownum < 5 )
Thanks!!
Regards
Gouri

Lock Cascade With Select for UPDATE

If I had a employee table and a phone table with a parent/child relationship and a primary key constraint on the employee table-will issuing a select for update on the employee also lock the corresponding child rows on the phone table ?
If not how can I bring this about ?

You only need two sessions:
First session: Issue the 'select for update'
statements for the row(s) in both tables, don't
rollback or commit
Second session: try to update a row that you tried to
lock in the first session (with NOWAIT).
Thanks. I can try this definitely. A basic question.
You are asking me to do a join on both the tables right ?
Not two individual SQL statements ?
Updating the primary key is known as a Bad Idea (tm).
The key should never be touched because it should be
meaningless. When you have a column that holds 'real'
information it is no candidate for a primary key.
Rgds,
GuidoYes I am aware of that. I was just wondering what is the meaning behind this statement from this link ?
http://www.akadia.com/services/ora_locks_survival_guide.html
And the exact phrase from that link under the section Referential Integrity Locks (RI Locks)
"RI constraints are validated by the database via a simple SELECT from the dependent (parent) table in question-very simple, very straightforward. If a row is deleted or a primary key is modified within the parent table, all associated child tables need to be scanned to make sure no orphaned records will result. "
Thanks again.

Deadlock detected during SELECT FOR UPDATE - an application error?

I have a general question about how Oracle prevents deadlocks from affecting
applications: do I need to build support into the application for handling
deadlocks when they occur in this particular scenario, or should Oracle handle
this for me? I'd like to know whether this is "normal" behavior for an Oracle
application, or if there is an underlying problem. Consider the following situation:
Two sessions issue individual SELECT FOR UPDATE queries. Each query locates
records in the table using a different index. These indexes point to rows in a
different order from each other, meaning that a deadlock will occur if the two
statement execute simultaneously.
For illustrative purposes, consider these rows in a hypothetical table.
ALPHABET
alpha
bravo
charlie
delta
echo
foxtrot
golf
hotel
Index A results in traversing the table in ascending alphabetical order; index
B, descending. If two SELECT FOR UPDATE statements concurrently execute on this
table--one with an ascending order execution path and one in descending order--
the two processes will deadlock at the point where they meet. If Session A
locks alpha, bravo, charlie, and delta, while Session B locks hotel, golf,
foxtrot, and echo, then neither process can proceed. A needs to lock echo, and
B needs to lock delta, but one cannot continue until the other releases its
locks.
This execution path can be encouraged using hints. Executing queries similar to these on larger tables will generate the "collision" as described above.
-- Session A
select /*+ index_asc (customer) */
from customer
where gender = 'M'
for update;
-- Session B
select /*+ index_desc (customer) */
from customer
where gender = 'M'
for update;
Oracle will recognize that both sessions are in a stand-off, and it will roll
back the work performed by one of the two sessions to break the deadlock.
My question pivots on whether or not, in this situation, the deadlock gets
reported back to the application executing the queries as an ORA-00060. If
these are the ONLY queries executed during these sessions, I would think that
Oracle would rollback the locking performed in one of the SELECT FOR UPDATE
statements. If I understand correctly,
(1) Oracle silently rolls back and replays work performed by UPDATE statements
when a deadlock situation occurs within the scope of the update statement,
and
(2) A SELECT FOR UPDATE statement causes Oracle, at the point in time the cursor
is opened, to lock all rows matching the WHERE clause.
If this is the case, then should I expect Oracle to produce an ORA-00060
deadlock detection error for two SELECT FOR UPDATE statements?
I would think that, for deadlock situations completely within Oracle's control,
this should be perceived to the application invoking the SELECT FOR UPDATE
statements as regular blocking. Since the query execution plans are the sole
reason for this deadlock situation, I think that Oracle would handle the
situation gracefully (like it does for UPDATE, as referenced in (1)).
Notice, from the trace file below, that the waits appear to be from row locking,
and not from an artificial deadlock (e.g. ITL contention).
Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
With the Partitioning option
DEADLOCK DETECTED
Current SQL statement for this session:
SELECT XXX FROM YYY WHERE ZZZ LIKE 'AAA%' FOR UPDATE
----- PL/SQL Call Stack -----
object line object
handle number name
58a1f8f18 4 anonymous block
58a1f8f18 11 anonymous block
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-002f004b-000412cf 37 26 X 26 44 X
TX-002e0044-000638b7 26 44 X 37 26 X
session 26: DID 0001-0025-00000002 session 44: DID 0001-001A-00000002
session 44: DID 0001-001A-00000002 session 26: DID 0001-0025-00000002
Rows waited on:
Session 44: obj - rowid = 0000CE31 - AAANCFAApAAAAGBAAX
Session 26: obj - rowid = 0000CE33 - AAANCHAArAAAAOmAAM
Thanks for your insight,
- Curtis
(1) "Oracle will silently roll back your update and restart it"
http://tkyte.blogspot.com/2005/08/something-different-part-i-of-iii.html
(2) "All rows are locked when you open the cursor, not as they are fetched."
http://download-east.oracle.com/docs/cd/A87860_01/doc/appdev.817/a77069/05_ora.htm#2170
Message was edited by:
Curtis Light

Thanks for your response. In my example, I used the indexes to force a pair of query execution plans to "collide" somewhere in the table in question by having one query traverse the table via index in an ascending order, and another in descending. This is an artificial scenario for reproducible illustrative purposes, but similar collisions could legitimately occur in real world scenarios (e.g. a full table scan and an index range scan with lookup by ROWID).
So, with that said, I think it would be unreasonable for Oracle to report the collision as a ORA-00060 every time it occurs because:
(1) The UPDATE statement handles this situation automatically, and
(2) An ORA-00060 results in a 100+KB trace file being written out, only rational for truly erroneous situations.
I agree that, when the application misbehaves and locks rows out of order in separate SQL statements, then Oracle should raise an ORA-00060, as the deadlock is outside of its control. But in this case, the problem occurs with just two individual SQL statements, each within its own transaction.

SELECT - INSERT/UPDATE statement mapping.

Similar Messages

Maybe you are looking for