On Mon, Mar 21, 2011 at 9:02 AM, Mike Pomraning
<mjp@...> wrote:

> On Mon, Mar 21, 2011 at 1:10 AM, karolbieniaszewski
> <liviuslivius@...> wrote:
>>
>> --- In firebird-support@yahoogroups.com, Mike Pomraning <mjp@...> wrote:
>> >
>> > On Sat, Mar 19, 2011 at 12:47 PM, homerjones1941 <homer@...>wrote:
>> > > Can you declare a variable, and then just assign the value once?
>> > >
>> >
>> > In a stored procedure, yes. IMHO this is suitable for regular,
>> > production
>> > environments, when you already know all the queries you want to run.
>> > However, I find it too restrictive for general or "on the fly" querying.
>> >
>> > Another possibility is using a table or GTT or RDB$SET_CONTEXT() to
>> > store
>> > the precomputed value. In this case you'd have to explicitly compute the
>> > value before every SELECT, which is still cumbersome but more flexible
>> > IMHO
>> > than using a stored procedure.
>> >
>> > But, I'm wondering if there is an easier technique than any of the
>> > above.
>> >
>> > -Mike
>> >
>> >
>> > [Non-text portions of this message have been removed]
>> >
>>
>> Yes exists "better" way
>> What problem with this i suppose that you write some client application?
>>
>> Select "your_date_time_utc", x, y, z from table_x ..
>
> Thanks, Karol.  Client-generated timestamps are susceptible to the vagaries
> of every client's clock, or require the client to execute two queries:
> SELECT server's time, then issue the query we care about.
>
> Hmm, is there a way in the API to determine the transactional scope of the
> currently executing query, finer-grained than CURRENT_TRANSACTION?  I
> suppose CURRENT_TIMESTAMP effectively serves that purpose.

It occurs to me that this naive caching keyed on CURRENT_TIMESTAMP
will be incorrect during some daylight savings changes, when an hour
repeats itself. Drat.

-Mike