Embedded SQL against Oracle Question

Question

Software: Forte 3.0.J.
Server Platform: HPUX 10.2
Database: Oracle
Problem Description: During the course of development, I ran into a
problem using multiple columns in an sql UPDATE/SET statement. I was trying
to update a.COLUMN_1 and a.COLUMN_2, which constitute part of the primary
key of associative TABLE_A (a). In order for me to make the update, I
needed to use the existing value of a.COLUMN_1 to lookup the new b.COLUMN_1
in TABLE_B (b). Where a.COLUMN_1 = b.RELATED_COLUMN_1, I am able to find
each b.COLUMN_2 that correspond to each a.COLUMN_2.
I was able to resolve the issue by separating the two columns so
that each had it's own select statement. Theoretically, it appears that
this shouldn't work, because the SET statement for a.COLUMN_1 would cause
the a.COLUMN_1 reference in the select statement of a.COLUMN_2 to be
overwritten.
In spite of this, I tried it, and it worked. I would like to
understand why the sql works, and how sql actually executes the statement.
Here is the sql:
UPDATE TABLE_A a
SET a.COLUMN_1 =
(SELECT DISTINCT b1.COLUMN_1
FROM TABLE_B b1
WHERE b1.RELATED_CASE_ID =
a.COLUMN_1 AND
b1.RELATED_COLUMN_TYPE_CD = 'NEPHI'),
a.COLUMN_2=
(SELECT DISTINCT b2.COLUMN_2
FROM TABLE_B b2
WHERE b2.RELATED_COLUMN_1=
a.COLUMN_1 AND
b2.RELATED_COLUMN_TYPE_CD = 'NEPHI' AND
b2.RELATED_COLUMN_2= a.COLUMN_2)
WHERE a.COLUMN_1 = 100
The table structure is as follows:
TABLE_A: (primary keys are bolded) This is an associative table.
Column_1 and Column_2 comprise the pk of one table; Column_3 and Column_4
comprise the pk of another table. Assume that the Column_1 and Column_2
values replacing the original values already exist in the parent table of
which they form the pk).
COLUMN_1
COLUMN_2
COLUMN_3
COLUMN_4
COLUMN_5
TABLE_B: (primary keys are bolded) This is a reference table.
COLUMN_1
COLUMN_2
RELATED_COLUMN_1
RELATED_COLUMN_2
RELATED_COLUMN_TYPE_CD
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Answer 1

If you do an explain plan or set autotrace on against this update statement,
you'll find that the select operations are actually executed first by Oracle
- I believe because of the nature of the transaction. Thus, no problem.
Brian Wilson
U.S. Bancorp Piper Jaffray
[email protected]
Phone [phone]
From: David Pettit[SMTP:[email protected]]
Reply To: David Pettit
Sent: Friday, April 30, 1999 1:58 PM
To: '[email protected]'
Subject: Embedded SQL against Oracle Question
Software: Forte 3.0.J.
Server Platform: HPUX 10.2
Database: Oracle
Problem Description: During the course of development, I ran into a
problem using multiple columns in an sql UPDATE/SET statement. I was
trying
to update a.COLUMN_1 and a.COLUMN_2, which constitute part of the primary
key of associative TABLE_A (a). In order for me to make the update, I
needed to use the existing value of a.COLUMN_1 to lookup the new
b.COLUMN_1
in TABLE_B (b). Where a.COLUMN_1 = b.RELATED_COLUMN_1, I am able to find
each b.COLUMN_2 that correspond to each a.COLUMN_2.
I was able to resolve the issue by separating the two columns so
that each had it's own select statement. Theoretically, it appears that
this shouldn't work, because the SET statement for a.COLUMN_1 would cause
the a.COLUMN_1 reference in the select statement of a.COLUMN_2 to be
overwritten.
In spite of this, I tried it, and it worked. I would like to
understand why the sql works, and how sql actually executes the statement.
Here is the sql:
UPDATE TABLE_A a
SET a.COLUMN_1 =
(SELECT DISTINCT b1.COLUMN_1
FROM TABLE_B b1
WHERE b1.RELATED_CASE_ID =
a.COLUMN_1 AND
b1.RELATED_COLUMN_TYPE_CD = 'NEPHI'),
a.COLUMN_2=
(SELECT DISTINCT b2.COLUMN_2
FROM TABLE_B b2
WHERE b2.RELATED_COLUMN_1=
a.COLUMN_1 AND
b2.RELATED_COLUMN_TYPE_CD = 'NEPHI' AND
b2.RELATED_COLUMN_2= a.COLUMN_2)
WHERE a.COLUMN_1 = 100
The table structure is as follows:
TABLE_A: (primary keys are bolded) This is an associative table.
Column_1 and Column_2 comprise the pk of one table; Column_3 and Column_4
comprise the pk of another table. Assume that the Column_1 and Column_2
values replacing the original values already exist in the parent table of
which they form the pk).
COLUMN_1
COLUMN_2
COLUMN_3
COLUMN_4
COLUMN_5
TABLE_B: (primary keys are bolded) This is a reference table.
COLUMN_1
COLUMN_2
RELATED_COLUMN_1
RELATED_COLUMN_2
RELATED_COLUMN_TYPE_CD
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Nondeposit investment products are not insured by the FDIC, are
not deposits or other obligations of or guaranteed by U.S. Bank
National Association or its affiliates, and involve investment
risks, including possible loss of the principal amount invested.
Past performance does not guarantee future results. We consider
our sources reliable. Accuracy and completeness are not guaranteed.
Information is subject to change. Transactional details should not
be relied on for tax purposes and do not supersede normal trade
confirmations or statements. Messaging outside U.S. jurisdictions
from U.S. Bancorp Piper Jaffray to non-institutional parties is not
intended for solicitation purposes.
Electronic mail sent through the Internet is not secure. We will
not accept time-sensitive, action-oriented messages, transaction
orders, fund transfer instructions or check stop payments
electronically.
If you are not the intended recipient, notify the Sender. This
information is intended only for the person named above and for
the purposes indicated. Do not distribute this message without
written consent of the author. Non-business opinions may not
reflect opinions of U.S. Bancorp Piper Jaffray and its affiliates.
U.S. Bancorp Piper Jaffray and its affiliates reserve the right to
monitor all e-mail.
Securities products and services are offered through
U.S. Bancorp Piper Jaffray Inc., member SIPC and NYSE, Inc.,
a subsidiary of U.S. Bancorp.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>