I have 2 tables, one with names, and another with addresses, joined by their
CIVICID number (unique to the ADDRESSINFO table) in Oracle.

I need to update a field in the NAMEINFO table for a particular surname in a
particular town.

I can select the records fine with this syntax (testing in Oracle SQL* Plus)

SELECT NAMEINFO.LASTNAME, NAMEINFO.FIRSTNAME, NAMEINFO.MIDDLENAME,
NAMEINFO.GENDER, ADDRESSINFO.REGION FROM NAMEINFO, ADDRESSINFO WHERE
ADDRESSINFO.CIVICID =NAMEINFO.CIVICID (+) AND 'Smith'=NAMEINFO.LASTNAME AND
'Moncton'=ADDRESSINFO.TOWN;

However, I tried to update the names and failed. Here is my syntax:
UPDATE NAMEINFO SET NAMEINFO.FLAG= 'OK' WHERE ADDRESSINFO.CIVICID
=NAMEINFO.CIVICID (+) AND (('Smith'=NAMEINFO.LASTNAME) AND
('Moncton'=ADDRESSINFO.TOWN));


Is there anyway to update the FLAG field with using a Where clause using
bits of 2 tables?
I can do it in Access, using the GUI, but the syntax is different between
the 2 databases...

Help!

"Dave" <nospam (AT) nospam (DOT) com> wrote:

Hi, Dave. I think the syntax would be:

UPDATE NAMEINFO

SET NAMEINFO.FLAG = 'OK'

FROM NAMEINFO [LEFT OUTER(?)] JOIN ADDRESSINFO
ON NAMEINFO.CIVICID = ADDRESSINFO.CIVICID

WHERE NAMEINFO.LASTNAME = 'SMITH'
AND ADDRESSINFO.TOWN = 'MONTCON';

I can't reach an Oracle server from here, so I didn't test this, but it's
very standard SQL (not that that means anything to Oracle). Essentially,
the problem is that you omitted the FROM clause. You can't refer to a table
in a WHERE clause that isn't named in the FROM clause.

There are so many maddening things about Oracle, that I'm not guaranteeing
this will work. It would work on any database grounded in relational
theory, but I looked forward to the chance to work with Oracle for years,
and I've been disappointed to discover that virtually everything about
Oracle is ad-hoc and based on no theory at all. Every day, I waste hours
trying to figure out why entirely ordinary things just don't work in Oracle
('Oh, you need to have some proprietary PRAGMA if you want to do that').

I hope I don't infuriate anyone for whom Oracle is a religion by saying
this. I've spent my career interested in relational theory without respect
to any particular implementation.

A couple of comments. First, JOINS should never be done in the WHERE
clause. That's an archaic construction. They should be done using the
appropriate JOIN syntax; this keeps the distinction between joins and
restricts clear. I wasn't sure whether or why you were trying to do an
outer join, so I put that part of the syntax in brackets. I can't see any
reason for an outer join in the query, but of course, I don't know what
you're trying to do.

Finally, restrict conditions should always be written as COLUMN = Value, not
the other way 'round. It will work either way, but it isn't logical to
write Value = COLUMN.

I hope this was helpful.

Brian

Nope! There is no FROM clause in a Standard SQL UPDATE statement; it
would make no sense. Other products (SQL Server, Sybase and Ingres)
also use the UPDATE .. FROM syntax, but with **different** semantics.
So it does not port, or even worse, when you do move it, it trashes
your database. Other programmers cannot read it and maintaining it is
harder.

The correct syntax for a searched update statement is

<update statement> ::=
UPDATE <table name>
SET <set clause list>
[WHERE <search condition>]

<set clause list> ::=
<set clause> [{ , <set clause> }...]

<set clause> ::= <object column> = <update source>

<update source> ::= <value expression> | NULL | DEFAULT

<object column> ::= <column name>

The UPDATE clause simply gives the name of the base table or updatable
view to be changed.

Notice that no correlation name is allowed in the UPDATE clause; this
is to avoid some self-referencing problems that could occur. But it
also follows the data model in Standard SQL. When you give a table
expression a correlation name, it is to act as if a materialized table
with that correlation name has been created in the database. That
table then is dropped at the end of the statement. If you allowed
correlation names in the UPDATE clause, you would be updating the
materialized table, which would then disappear and leave the base
table untouched.

The SET clause is a list of columns to be changed or made; the WHERE
clause tells the statement which rows to use. For this discussion, we
will assume the user doing the update has applicable UPDATE privileges
for each <object column>.

* The WHERE Clause

As mentioned, the most important thing to remember about the WHERE
clause is that it is optional. If there is no WHERE clause, all rows
in the table are changed. This is a common error; if you make it,
immediately execute a ROLLBACK statement.

All rows that test TRUE for the <search condition> are marked as a
subset and not as individual rows. It is also possible that this
subset will be empty. This subset is used to construct a new set of
rows that will be inserted into the table when the subset is deleted
from the table. Note that the empty subset is a valid update that
will fire declarative referential actions and triggers.

* The SET Clause

Each assignment in the <set clause list> is executed in parallel and
each SET clause changes all the qualified rows at once. Or at least
that is the theoretical model. In practice, implementations will
first mark all of the qualified rows in the table in one pass, using
the WHERE clause. If there were no problems, then the SQL engine
makes a copy of each marked row in working storage. Each SET clause
is executed based on the old row image and the results are put in the
new row image. Finally, the old rows are deleted and the new rows are
inserted. If an error occurs during all of this, then system does a
ROLLBACK, the table is left unchanged and the errors are reported.
This parallelism is not like what you find in a traditional
third-generation programming language, so it may be hard to learn.
This feature lets you write a statement that will swap the values in
two columns, thus:

UPDATE MyTable
SET a = b, b = a;

This is not the same thing as

BEGIN ATOMIC
UPDATE MyTable
SET a = b;
UPDATE MyTable
SET b = a;
END;

In the first UPDATE, columns a and b will swap values in each row. In
the second pair of UPDATEs, column a will get all of the values of
column b in each row. In the second UPDATE of the pair, a, which now
has the same value as the original value of b, will be written back
into column b -- no change at all. There are some limits as to what
the value expression can be. The same column cannot appear more than
once in a <set clause list> -- which makes sense, given the parallel
nature of the statement. Since both go into effect at the same time,
you would not know which SET clause to use.

If a subquery expression is used in a <set clause>, and it returns a
single value, the result set is cast to a scalar; if it returns an
empty set, the result set is cast to a NULL; if it returns multiple
rows, a cardinality violation is raised.

this keeps the distinction between joins and restricts clear. <<

A lot of newbies (read: SQL Server by way of ACCESS) think that the ON
clause must hold the join condition and the WHERE clause must hold the
restrictions. This is not true. It can make for some nice code, and
might help a smart optimizer materialize common subexpressions across
mulitple queries, show you what should be in a VIEW, etc. But it is
not required.


My Arab and Chinese students used to do that, too!

UPDATE NameInfo
SET NameInfo.flag = 'OK'
WHERE NameInfo.lastname = 'Smith'
AND EXISTS
(SELECT *
FROM AddressInfo AS A1
WHERE A1.civic_id = NameInfo.civic_id
AND A1.town = 'Moncton');

Read the other posting about the proper syntax for an UPDATE.

jcelko212 (AT) earthlink (DOT) net (--CELKO--) wrote in message news:<18c7b3c2.0408071532.174d4354 (AT) posting (DOT) google.com>...
What do you mean that no correlation name is allowed? You can place a
table name (correlation) label on an update, otherwise how would you
perform co-ordingated subqueries? (Code runs on Oracle 7.0 - 9.2)

update wo_routing a
set bkf_flag = 'N'
where oper_seq < (select max(oper_seq) from wo_routing b
where order_no = a.order_no
and work_center_no = a.work_center_no
and plant = a.plant)
and plant = F_plant
and order_no = F_order_no;

Maybe I misunderstand the use of the term in this context.

HTH -- Mark D Powell --

would you perform co-ordingated subqueries? (Code runs on Oracle 7.0 -
9.2) <<

NOT in Standard SQL; look it up!

"Caesar: Pardon him, Theodotus. He is a barbarian and thinks the
customs of his tribe and island are the laws of nature." - Caesar and
Cleopatra; George Bernard Shaw 1898

It would make no sense. The ANSI/ISO model is that a correlation
creates a temporaty working table with that name and the data of the
table expression on the left hand side of the AS operator. You also
have the option of renaming the columns in the new table.

This means that the working table, not the base table, would be
updated and then disappear.

jcelko212 (AT) earthlink (DOT) net (--CELKO--) wrote in message news:<18c7b3c2.0408121154.3b0949a6 (AT) posting (DOT) google.com>...
This is probably just a terminology problem, more likely on my part,
on what is meant by correlation. I looked in the MS SQL manual and
they also support coordinated subquery on an update. I am sure this
also works in DB2 so it seems unlikely that the table label "A" in my
example represents any type of correlation as meant by the standard.

-- Mark D Powell --

well, the standard is well known, thank you for explaining it again.
I think the reason we do not follow it is also very simple: the
standard is VERY inconvenient in many simple real life situations...

What do you think?