30.08.2019 19:25, Mark Rotteveel wrote:
Have you never used tools or libraries that didn't support newer features of
Firebird?
Yes. I was able to workaround most of incompatibilities but at the end it was easier to
drop these libraries and use API directly.
About tools: isql supports
Alex Peshkoff via Firebird-devel
wrote Fri, 30 Aug 2019 16:10:12 +0300:
I see only one problem with SQL-style management - if old application
can't issue arbitrary SQL how to tune it to use legacy/char format? On
the other hand: how at all will such application use new DB format? SQL
Could you explicitly describe the problem you think this solves, and how
your proposal solves it?
BTW: This subject says TIME WITH TZ, but I assume it also applies to
TIMESTAMP (with time zone)
On 2019-08-30 13:48, Alex Peshkoff via Firebird-devel wrote:
Hi all!
From discussion in a thread
On 2019-08-30 15:36, Dimitry Sibiryakov wrote:
30.08.2019 15:27, Alex Peshkoff via Firebird-devel wrote:
For some applications that makes sense.
Look: you have an old database without new data types and an old
application that works with it. The only way to put this old
application into
On 30/08/2019 08:56, Dmitry Yemanov wrote:
> 27.08.2019 3:59, Adriano dos Santos Fernandes wrote:
>>
>> Sometimes a object managed by memory-pool may embed non-pooled memory or
>> other resources.
>>
>> If the main object is not explicitly destroyed, i.e., destroyed by pool,
>> the embedded
On 30/08/2019 08:48, Alex Peshkoff via Firebird-devel wrote:
>
>
> 1. Let's use SQL subtype in order to represent in the message UTC or
> regional time, i.e. for time with time zone 2 subtypes will make sense
> - UTC format or regional format. When user provides message format
> information in
30.08.2019 15:57, Vlad Khorsun wrote:
You have never worked in environment where database evolving constantly and
there is
a lot of old a new apps that should work together for a some (probably long)
time.
One must be a real genius to add new tables and new fields preserving backward
30.08.2019 16:36, Dimitry Sibiryakov wrote:
30.08.2019 15:27, Alex Peshkoff via Firebird-devel wrote:
For some applications that makes sense.
Look: you have an old database without new data types and an old application that works with it. The only way to put this old
application into
30.08.2019 15:27, Alex Peshkoff via Firebird-devel wrote:
For some applications that makes sense.
Look: you have an old database without new data types and an old application that works
with it. The only way to put this old application into troubles is to _change_ type of an
old field
On 30.08.2019 16:12, Dimitry Sibiryakov wrote:
30.08.2019 15:10, Alex Peshkoff via Firebird-devel wrote:
why use new datatype at all?
That's a very good question.
You took my words out of context... For some applications that makes sense.
Firebird-Devel mailing list, web interface at
30.08.2019 15:10, Alex Peshkoff via Firebird-devel wrote:
why use new datatype at all?
That's a very good question.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 30.08.2019 15:46, Dimitry Sibiryakov wrote:
30.08.2019 14:29, Dmitry Yemanov wrote:
Which sqltype value is provided by isc_dsql_prepare/describe_bind
is irrelevant as long as application can override it.
But 99.9% existing (at the moment) applications cannot override
unknown for them
30.08.2019 14:29, Dmitry Yemanov wrote:
Which sqltype value is provided by isc_dsql_prepare/describe_bind is irrelevant as
long as application can override it.
But 99.9% existing (at the moment) applications cannot override unknown for them data
type. So the BIND option may still be good
30.08.2019 15:24, Dimitry Sibiryakov wrote:
30.08.2019 13:48, Alex Peshkoff via Firebird-devel wrote:
...
3. This solution is for really old clients which anyway can not work with new time formats - use of alternate binding to character
string (like with decimal float values). Syntax is more
30.08.2019 15:24, Dimitry Sibiryakov wrote:
3. This solution is for really old clients which anyway can not work
with new time formats - use of alternate binding to character string
(like with decimal float values). Syntax is more or less same:
SET TIME ZONE BIND {NATIVE | LEGACY | CHAR}
30.08.2019 13:56, Dmitry Yemanov wrote:
Which is usually good per se, unless performance is affected (e.g. millions of small
objects inside the pool).
Which is a bad idea per se but if these object has no destructor compiler won't
generate its call. Operator delete[] instead of individual
30.08.2019 13:48, Alex Peshkoff via Firebird-devel wrote:
Suggested solution is use of flexible format letting each client to receive data from the
server in a best fit way. To tune that format three parameters will be used - together
they make it possible to have 6 different formats - 4
27.08.2019 3:59, Adriano dos Santos Fernandes wrote:
Sometimes a object managed by memory-pool may embed non-pooled memory or
other resources.
If the main object is not explicitly destroyed, i.e., destroyed by pool,
the embedded objects leak.
True. And this requires us to avoid the
Hi all!
From discussion in a thread "Could not find acceptable ICUlibrary"
it's getting clear that we can not satisfy all requirements to time with
timezone fields (when exchanging client/server messages) in single
format because they (requirements) are too contradictory. Suggested
solution
19 matches
Mail list logo
