I would strongly discourage the use of SQL for such a task (or any other task for that matter).
When a test result changes (and here I assume that you're referring to the execution status of a test instance), many other fields can change : the last execution status of the test, the coverage status of any linked requirement to name a few. Moreover, other built-in mechanisms can be triggered, such as sending a mail to "someone" because of a linked defect.
I understand your point, Christian. The safest way to update test results is through UI within QC framework, meaning executing scripts from QC and letting QC handle result log. What we try to do here is to execute test from QTP and post the results back to QC.
In my case of #1, everything looks good and I updated test results in 3 levels (Test, Last Run, Run steps). I would expect #2 can do the same using tdc.Command.
I could add a defect through #1 and populate my custom error descriptions to defect object. Don't know if sending an email is by database trigger or not, but through OTA automation engineers have more controls on all this.
This is what I like QTP -- provide APIs for us to do more on our own.
We have data-driven framework which each action deals with one function area and covers all naviation paths in the area. With action datasheets we can loop through a great amount of iteration with various data combinations.
This will not be as efficient using QC by splitting each iteration into one script and passing input data (more importantly maintaining them) as using QTP framework.