At 12:35 PM 15/09/2003 +0000, you wrote:

>--- In firebird-support@yahoogroups.com, "kumasoftllc"
><kumasoftdev@b...> wrote:
> > I have discovered that the value returned by current_timestamp is
> > fixed within the scope of any given stored procedure call.
>
>Generally speaking, within in a transaction, every functio
>you call is required to give the same result for the same
>arguments. For functions taking no arguments, as current_timestamp,
>this implies fixed results.
>
>A transaction freezes the environment for consistency of its operation.

Actually, the timestamping occurs when the operation starts, not when the
transaction starts. So, if you have a procedure that performs a number of
operations, each operation will have a different timestamp. If one
operation operates on multiple rows, all of those rows will get the same
timestamp.

A transaction and a procedure call are not necessarily 1:1. It's fairly
typical to perform a group of tasks within a single transaction, involving
multiple requests from the client. In bad applications, that single
transaction could last for hours.

>Sad that, and just short of quoting holy scriptures, I'm under
>the impression, that SQL implementations conforming to the
>standard in this point, almost always have a backdoor for those
>pesky users who want it otherwise. As Helen noted, this backdoor
>for Firebird may have been accidentically shut closed.

I'm not so sure that it matters a lot. If you have an operation that
performs the same DML on a large number of rows in one hit, and you were
interested in atomicity, why would you care about what order they were
performed in?

heLen