> You have it. It's the version before you upgrade the table.
You mean before the server was upgraded?
> That in practice is a complexity nobody will use in this way.
I agree with you, partially. 90% developers will jsut store the timestamp with
timezone and done. Occasionally they will be su
On 24/04/2019 14:44, Adriano dos Santos Fernandes wrote:
Data should be validated/fixed when new rules are installed.
So IMO the problem is letting OS (or some shared component) be the
master of time zones rules instead of Firebird engine having its own
controlled table.
Exactly ...
And the fa
On 24/04/2019 09:57, Jiří Činčura wrote:
>> I'm not against tools to help one fix timestamps after rule change, but
>> definitively that should be tools, not the storage of values that should
>> be changed.
> What I'm trying to say, that simply storing in UTC+TZ is not enough, because
> at the min
> I'm not against tools to help one fix timestamps after rule change, but
> definitively that should be tools, not the storage of values that should
> be changed.
What I'm trying to say, that simply storing in UTC+TZ is not enough, because at
the minimum you need at least (1) the TZ data version
On 24/04/2019 03:53, Jiří Činčura wrote:
>> That is not a problem. The ambiguity exists only when transforming a
>> timestamp+TZ (as one sees it) to UTC. After parse the literal, it's
>> always in UTC+TZ.
>>
>> UTC+TZ is always transformed to a valid displayable timestamp+TZ.
> That is a BIG proble
> Would something like this be better:
> -> Index "PK_DYREKCJA" Full Scan (ordered by < field name(s) >)
>
> ?
>
Mayby changing "Full Scan" name here is better? To e.g. "Ordered Retrival"
or
Full Scan (ordered)
or
Order Index "PK_DYREKCJA" Full Scan
>>> If so, should it be printed for looku
24.04.2019 10:03, liviuslivius wrote:
i have looked at this simple explained plan and i see that from it i
cannot read simply that result set is sorted and retrived by index.
Select Expression
-> Nested Loop Join (inner)
-> Filter
-> Table "DYREKCJA" as "D" Access By
Hi
i have looked at this simple explained plan and i see that from it i cannot
read simply that result set is sorted and retrived by index.
Select Expression
-> Nested Loop Join (inner)
-> Filter
-> Table "DYREKCJA" as "D" Access By ID
-> Index "PK_DYREK
