Re: Theoretical Basis for SELECT FOR UPDATE

On 4 Oct 2005 12:37:15 -0700, "vc" <boston103_at_hotmail.com> wrote:

>Gene Wirchenko wrote:
>> On 4 Oct 2005 07:54:24 -0700, "vc" <boston103_at_hotmail.com> wrote:

[snip]

>> Please read more carefully. He has repeatedly said that he is
>> working on large apps that have had many programmers.
>
>Ah, sorry I missed that. But you can hardly blame the tools for the
>programmers unwillingness to use them. By tools, I mean the very well

     If the situation is that such tools have not been used, it is too late. The situation is there.

>known stuff like stored procedures, Java/C++/whatever classes that
>allow one to structure the code. It's extremely naive to think that
>the S1,S2,..,Sn notation will lead to better coding practices in
>comparison to the S1;S2;...;Sn;commit; one. I'd hope that the database
>programmer would use stored procedures, or some such, even with the
>modern notation.

     It is not merely a notation. It is an entire transaction. In multiple statement DBMS code, non-DBMS statements can be inserted between the DBMS statements. With but one DBMS statement, there is no between.

>> The problem with walking into such a situation is that anything
>> could have happened.
>
>One can always walk out, a matter of chpice, no ?

     Sure. But the situation remains and will have to be dealt with in some way by someone.

[snip]

>> With SQL statements just about anywhere, how do you isolate
>> exactly what that transaction is? Yes, there may be a way for you to
>> do it with the way that you code, and if others coded as you do, there
>> would be no problem. However, since others are not restricted to your
>> way, they can do pretty much anything. That has to be untangled. Mr.
>> Hann is saying that it can not be done very easily at all.

>If what you ("you" is an impersonal pronoun here) are doing is reverse
>engineering the existing code without any documentation or even oral
>tradition, then yes it is tough.

     That has been Mr. Hann's point. It can be hairy enough me digging into old code of mine. I, at least, know how I think. All bets are off when it is someone else's code. The same applies when someone else looks at my code.

Sincerely,

Gene Wirchenko Received on Wed Oct 05 2005 - 00:08:33 CEST