"why would you care about what order they were performed in?"

Because I am interested in performing some temporal analysis on the performance of RC6. I have a load procedure that simulates the migration of data from an external source. My initial timings with a clock were showing RC6 to be 50% slower than RC5 with the same hardware and schema. Since, the tables being loaded contain a timestamp that is loaded via a trigger (using current_timestamp) I tried to analyze the number of records that were loaded per minute which is how I noticed that all the records were carrying the same value despite the process taking several hours to run. The bulk of my experience is with Oracle which has obviously chosen to implement the specification differently as its "sysdate" variable always returns the current point in time. I will try using the udf that you suggested.

By the way, has anyone else noticed that RC6 seems to be significantly slower than RC5?

"In bad applications, that single transaction could last for hours"

Unfortunately, Firebird does not allow commits/rollbacks within a stored procedure so this makes it difficult for transactions to be kept short with the type of process that I am running. Once again, coming from an Oracle background (in which transactional control IS allowed within stored procedures) this is a new issue for me. Perhaps I should be using Delphi to create external processes as that would allow me to shorten the transactions. How are such processes (the regularly scheduled synchronizations of large volumes of data) typically handled in a Firebird environment?


Thanks.

Bob


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


_______________________________________________________