Subject | Re: Making evaluation of UDFs constant across a query |
---|---|
Author | karolbieniaszewski |
Post date | 2011-03-22T06:42:14Z |
--- In firebird-support@yahoogroups.com, Mike Pomraning <mjp@...> wrote:
Only get UTC Time? What you do if you get this result what calculation?
Is this really needed? If yes then write in specification of your app that serwer should be start with UTC time settings..
Karol Bieniaszewski
>What exactly calculation with time you try to do?
> 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
>
Only get UTC Time? What you do if you get this result what calculation?
Is this really needed? If yes then write in specification of your app that serwer should be start with UTC time settings..
Karol Bieniaszewski