Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks

Lets say you were performing an sql update statement which was supposed to update one row in table A with details from exactly one row from table B because these 2 tables were supposed to have a common field and one row in table A will have the same value for this field as exactly one row in table B. The query would be like this:

The query might be something like
update table A, table B set A.field1 = B.field1 where A.field2 = b.fie +ld2

But what would happen if a row in table A actually matched 2 or more rows in table B? Lets say row 5 in table A matched rows 20 and 30 in table B. I am thinking row A will get updated with the value from table B row 20 and then will get updated again with the value from row 30 in table B, this overwriting the previous update

I am trying to simulate this as we speak. But my perl question is what would be the 'number of rows affected' returned by the do method

$rows_affected = $dbh->do($querystr);
Would it be the number of updates carried out even if the same row in table A was updated multiple times or would it just be one update as only one row in table A is ever updated? many thanks

Replies are listed 'Best First'.
Re: rows affected by an update command
by erix (Prior) on Nov 02, 2010 at 15:37 UTC

    Btw, if a table is 'supposed to be' one way or another, then it should be so constrained, so that the database won't allow any other state.

    See, for instance: constraints

    (INSERT ... RETURNING, if your database supports it, might be of interest too.)

Re: rows affected by an update command
by JavaFan (Canon) on Nov 02, 2010 at 15:14 UTC
    The answer you are seeking for is probably database dependent. I would say "what would happen" isn't a Perl question, it's a database question. The DBI would return as the number of rows affected whatever number the database returns.

    So, short of trying it out in your database, I suggest you consult the manuals of your database server. Or have a chat with your friendly neighbourhood database administrator.

      I don't have one of those :)

      If i run this query as a prepared statement, is there a way to print out the query that has been executed?

        See the TRACING section in the DBI documentation.

        -- Ken

        I don't have one of those :)
        If you don't have a database to try it out with, does it really matter what it returns? ;-)
Re: rows affected by an update command
by aquarium (Curate) on Nov 02, 2010 at 23:53 UTC
    what you are asking about is called referential integrity. there are different ways of handling it ,by the various DB engine implementations. The major DBs lag many years behind current SQL standard, and in any case, the SQL standard is a bit contentious etc..and in the end vendors try to come up with the goods in various ways.
    declarative referential integrity constraints are the most strict/rigid, and you always know exactly what happens when an anomally happens. But the typical implementation of many DB engines is through the use (and abuse) of triggers. triggers are database events (such as update to a table) that you can assign code to. this is very shonky though, as you have to write own code to do whatever you want when an update to a particular table column occurs. however if rigour is applied, you could theoretically end up with something implementing declarative referential integrity through the use of triggers. mind you, you have code (triggers) hanging off here and there and everywhere..and referential integrity is really a basic premise of a relational database. some DB engines even require you to set up triggers just to set up basic table relationships, as they treat each table as basically an independent entity.
    back to your question...what happens is if there are referential integrity constraints of any sort on the tables concerned, then these apply; otherwise if there's no table relationship & referential integrity constraints whatsoever you end up updating exactly what matched, in an atomic (all happens at once) way. so the UPDATE statement (if constraints are absent) would affect the same rows that you would changing it into a SELECT statement.
    the hardest line to type correctly is: stty erase ^H