""Ivan Prenosil"" <Ivan.Prenosil@...> wrote in message
news:<00c901c57260$074f6dc0$0e0110ac@prenosil>...

> > I'm mainly concerned with compatibility with other databases that DO

allow

> > commits and rollbacks and that sometimes it makes sense.
>
> You are a bit confused by the term "stored procedure",
> simply because different systems use it to refer to completely
> different things.
> In Firebird, stored procedure is sql command, and as any other
> sql commands it is executed as atomic piece of code inside
> transaction, where life cycle on transaction is controlled
> by application.
> The other databases you are talking about use the term "stored
> procedure" to describe "stored script" or "stored macro" or whatever.

I'm not confused, but I think you are...what in the heck are you talking
about in the above statement?
It's a stored procedure just like Firebird, but it supports commits and
rollbacks.

>
> > Such as databases that allow a Stored Procedure (SP) to be called by the
> > engine when it initially boots up.
> > Or databases that allow you to schedule task which make calls to SP.
>
> Do those databases allow calling single statement, like Delete, without
> using their SP ?

Yes, why wouldn't it? Are you sure you know what a stored procedure is?

>
> > So just as you have "your" reasons for not having commits/rollbacks in

SP, other

> > database developers have found a real need for them...and I agree.
>
> I am not questioning your need for some feature.
> I understand your reasons for wanting to easily run bunch of statements,
> including commits/rollbacks, stored somewhere in the database.
> The only problem is that you want to implement it in inproper place.
> You just want new feature, something like Stored Script.

???