Why READ ONLY transactions?

Robert Treat wrote:
> On Sat, 2003-07-26 at 21:31, Gavin Sherry wrote:
>>>> - Read only transactions, bringing a greater level of security to web and
>>>> enterprise applications by protecting data from modification.

>> This should be removed. Even though I added it to the press release,
>> I've just realised it's not really a security measure against SQL
>> injection since injected code can just specify 'SET TRANSACTION READ
>> WRITE'. We should still mention it, but not as a security measure.

> Aside from spec compliance, whats the bonus for having it then? Or put
> a better way, why/when would I want to use this?

If I am writing a "report program" that isn't supposed to do any
updates to anything, then I would be quite happy to set things to
READ-ONLY as it means that I won't _accidentally_ do updates.

It's like adding a pair of suspenders to your wardrobe. You can
_always_, if you really try, get your pants to fall down, but this
provides some protection.

I would NOT call it a "security" provision, as it is fairly easily
defeated using SET TRANSACTION.

But it's a nice discipline...

We can tell people:

"When you are writing report programs, start them off by setting
transactions to be READ-ONLY. That means that you won't modify data
by accident."

That's a useful sort of "Best Practice," for those organizations that
are into that sort of thing.
--
let name="cbbrowne" and tld="libertyrms.info" in name ^ "@" ^ tld;;
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)