> That's why you don't make a DBMS (SQL) do the job of a programming > language. Use your programming language to to retrieve the values you > need to make your calculations. Then use your programming language to > figure out the new values and execute the UPDATE commands needed to > make the changes. > > SQL is not a programming language. Trying to use it like one leads to > ridiculous contortions which take longer to run than doing it all in > SQL would take. There's nothing magically fast about SQL, it still has > to do the same amount of work in the end.
While I tend to side with others that have responding to this, there is some sense to what you're saying. SQL isn't a particularly good procedural language, but for set manipulation, it's excellent. Updating records *is* one of SQL's primary jobs. The idea that I cannot update multiple fields on one record based on the values of another record without going through several non-SQL programming hoops or including the same sub-select for every field is a little absurd. A decent query optimizer can create far more efficient code with an UPDATE FROM or Oracle syntax. Marc _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
