On 20/09/2019 09:29, Alex Peshkoff via Firebird-devel wrote:
> On 18.09.2019 4:13, Adriano dos Santos Fernandes wrote:
>
>> In API, but I'm not completely satisfied with solutions as they were
>> done related to above problems.
>>
>> Preferable settings should be done on statement basis,
>
> We hav
On 18.09.2019 4:13, Adriano dos Santos Fernandes wrote:
In API, but I'm not completely satisfied with solutions as they were
done related to above problems.
Preferable settings should be done on statement basis,
We have a problem with that approach. Cursor may be opened not only
using prepar
18.09.2019 12:11, Alex Peshkoff via Firebird-devel wrote:
For these API function to be useful, they must return localized region names according
to current OS settings. I don't think that it is doable in Firebird client API.
May be they should use current connection charset?
Traditionally
On 18.09.2019 12:23, Dimitry Sibiryakov wrote:
18.09.2019 3:13, Adriano dos Santos Fernandes wrote:
On 16/09/2019 08:21, Alex Peshkoff via Firebird-devel wrote:
On 16.09.2019 14:02, Adriano dos Santos Fernandes wrote:
There should be a way to client request additional data (tz offset, tz
regi
18.09.2019 3:13, Adriano dos Santos Fernandes wrote:
On 16/09/2019 08:21, Alex Peshkoff via Firebird-devel wrote:
On 16.09.2019 14:02, Adriano dos Santos Fernandes wrote:
There should be a way to client request additional data (tz offset, tz
region as string, string length) to be returned toge
On 16/09/2019 08:21, Alex Peshkoff via Firebird-devel wrote:
> On 16.09.2019 14:02, Adriano dos Santos Fernandes wrote:
>
>> There should be a way to client request additional data (tz offset, tz
>> region as string, string length) to be returned together with the data.
>> A general solution, not
On 2019-09-16 13:09, Alex Peshkoff via Firebird-devel wrote:
On 16.09.2019 14:03, Mark Rotteveel wrote:
On 2019-09-16 12:51, Alex Peshkoff via Firebird-devel wrote:
With ALTER SESSION DESCRIBE STATEMENT a number of problems with
extended timestamp format will be gone automatically. But one of k
16.09.2019 13:21, Alex Peshkoff via Firebird-devel wrote:
On 16.09.2019 14:02, Adriano dos Santos Fernandes wrote:
There should be a way to client request additional data (tz offset, tz
region as string, string length) to be returned together with the data.
A general solution, not a wrong speci
On 16.09.2019 14:02, Adriano dos Santos Fernandes wrote:
There should be a way to client request additional data (tz offset, tz
region as string, string length) to be returned together with the data.
A general solution, not a wrong specific/incomplete solution.
OK, that's not bad.
But on what
On 16.09.2019 14:03, Mark Rotteveel wrote:
On 2019-09-16 12:51, Alex Peshkoff via Firebird-devel wrote:
With ALTER SESSION DESCRIBE STATEMENT a number of problems with
extended timestamp format will be gone automatically. But one of key
problems remains - what can client do with timezone code wh
On 2019-09-16 12:51, Alex Peshkoff via Firebird-devel wrote:
With ALTER SESSION DESCRIBE STATEMENT a number of problems with
extended timestamp format will be gone automatically. But one of key
problems remains - what can client do with timezone code when it does
not know conversion rule for it.
On 16/09/2019 07:51, Alex Peshkoff via Firebird-devel wrote:
> With ALTER SESSION DESCRIBE STATEMENT a number of problems with
> extended timestamp format will be gone automatically. But one of key
> problems remains - what can client do with timezone code when it does
> not know conversion rule fo
With ALTER SESSION DESCRIBE STATEMENT a number of problems with extended
timestamp format will be gone automatically. But one of key problems
remains - what can client do with timezone code when it does not know
conversion rule for it.
A nice solutipn was already suggested by Vlad - extend tim
On 05.09.2019 17:25, Adriano dos Santos Fernandes wrote:
On 05/09/2019 10:59, Alex Peshkoff via Firebird-devel wrote:
On 05.09.2019 16:52, Adriano dos Santos Fernandes wrote:
Looks like finally you agreed that return a different tz value is
like
dropping a different database because engine cou
On 05/09/2019 10:59, Alex Peshkoff via Firebird-devel wrote:
> On 05.09.2019 16:52, Adriano dos Santos Fernandes wrote:
>
>> Looks like finally you agreed that return a different tz value is
>> like
>> dropping a different database because engine could not drop the
>> asked
>> o
On 05.09.2019 16:52, Adriano dos Santos Fernandes wrote:
Looks like finally you agreed that return a different tz value is like
dropping a different database because engine could not drop the asked
one, and no workaround should be inserted replacing region codes by
wrong offsets.
Why are you so
On 05/09/2019 10:52, Adriano dos Santos Fernandes wrote:
>
> Map (per user request, in API)
... or set binding statement.
> type to string.
>
>
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 05/09/2019 07:36, Alex Peshkoff via Firebird-devel wrote:
> On 05.09.2019 12:04, Lester Caine wrote:
>> On 05/09/2019 08:52, Alex Peshkoff via Firebird-devel wrote:
> Error is error, doesn't matter where it happens. Or you could
> offer
> "fallback" for
> wrong database handle
On 05.09.2019 12:04, Lester Caine wrote:
On 05/09/2019 08:52, Alex Peshkoff via Firebird-devel wrote:
Error is error, doesn't matter where it happens. Or you could offer
"fallback" for
wrong database handle\wrong server name in isc_attach_database\not
working client DNS\etc
cases ?
Looks li
On 05/09/2019 08:52, Alex Peshkoff via Firebird-devel wrote:
Error is error, doesn't matter where it happens. Or you could offer
"fallback" for
wrong database handle\wrong server name in isc_attach_database\not
working client DNS\etc
cases ?
Looks like finally you agreed that return a differ
05.09.2019 5:28, Adriano dos Santos Fernandes wrote:
On 04/09/2019 06:39, Vlad Khorsun wrote:
Error is error, doesn't matter where it happens. Or you could offer
"fallback" for
wrong database handle\wrong server name in isc_attach_database\not
working client DNS\etc
cases ?
Looks like fi
On 05.09.2019 5:28, Adriano dos Santos Fernandes wrote:
On 04/09/2019 06:39, Vlad Khorsun wrote:
Error is error, doesn't matter where it happens. Or you could offer
"fallback" for
wrong database handle\wrong server name in isc_attach_database\not
working client DNS\etc
cases ?
Looks like f
On 04/09/2019 06:39, Vlad Khorsun wrote:
>
> Error is error, doesn't matter where it happens. Or you could offer
> "fallback" for
> wrong database handle\wrong server name in isc_attach_database\not
> working client DNS\etc
> cases ?
>
Looks like finally you agreed that return a different tz
On 4-9-2019 11:39, Vlad Khorsun wrote:
04.09.2019 9:50, Mark Rotteveel wrote:
On 3-9-2019 08:35, Vlad Khorsun wrote:
03.09.2019 4:32, Adriano dos Santos Fernandes wrote:
On 02/09/2019 06:26, Alex Peshkoff via Firebird-devel wrote:
If even this causes problems offset may be displayed instead
04.09.2019 9:50, Mark Rotteveel wrote:
On 3-9-2019 08:35, Vlad Khorsun wrote:
03.09.2019 4:32, Adriano dos Santos Fernandes wrote:
On 02/09/2019 06:26, Alex Peshkoff via Firebird-devel wrote:
If even this causes problems offset may be displayed instead, i.e.
GMT+3. That's definitely trivial.
On 3-9-2019 08:35, Vlad Khorsun wrote:
03.09.2019 4:32, Adriano dos Santos Fernandes wrote:
On 02/09/2019 06:26, Alex Peshkoff via Firebird-devel wrote:
If even this causes problems offset may be displayed instead, i.e.
GMT+3. That's definitely trivial.
Fallback for the crazy situation of
On 03.09.2019 9:29, Vlad Khorsun wrote:
03.09.2019 4:20, Adriano dos Santos Fernandes wrote:
On 02/09/2019 08:06, Alex Peshkoff via Firebird-devel wrote:
ICU library often missing on windows client.
No, it's not, the C/C++ runtime causes much more problem in Windows than
ICU.
It is very f
03.09.2019 4:27, Adriano dos Santos Fernandes wrote:
On 02/09/2019 05:17, Vlad Khorsun wrote:
30.08.2019 19:15, Adriano dos Santos Fernandes wrote:
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,
03.09.2019 4:32, Adriano dos Santos Fernandes wrote:
On 02/09/2019 06:26, Alex Peshkoff via Firebird-devel wrote:
If even this causes problems offset may be displayed instead, i.e.
GMT+3. That's definitely trivial.
Fallback for the crazy situation of wrong client (without ICU) is
Not ag
03.09.2019 4:20, Adriano dos Santos Fernandes wrote:
On 02/09/2019 08:06, Alex Peshkoff via Firebird-devel wrote:
ICU library often missing on windows client.
No, it's not, the C/C++ runtime causes much more problem in Windows than
ICU.
It is very far from my own expirience
Regards,
Vlad
On 02/09/2019 06:26, Alex Peshkoff via Firebird-devel wrote:
>
> If even this causes problems offset may be displayed instead, i.e.
> GMT+3. That's definitely trivial.
>
Fallback for the crazy situation of wrong client (without ICU) is
already present: display gmt time with region "GMT*".
Craz
On 02/09/2019 05:17, Vlad Khorsun wrote:
> 30.08.2019 19:15, Adriano dos Santos Fernandes wrote:
>> 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 subtype
On 02/09/2019 08:22, Dimitry Sibiryakov wrote:
> 02.09.2019 13:16, Alex Peshkoff via Firebird-devel wrote:
>> How to make server always use offset (not timezone code) in selected
>> TS with TZ using coersion?
>
> Usual way for data coercion: application just set desired data type in
> metadata d
On 02/09/2019 08:06, Alex Peshkoff via Firebird-devel wrote:
> ICU library often missing on windows client.
No, it's not, the C/C++ runtime causes much more problem in Windows than
ICU.
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird
On 02.09.2019 14:30, Dimitry Sibiryakov wrote:
02.09.2019 13:27, Alex Peshkoff via Firebird-devel wrote:
May be OK for future versions.
..."but now we are going to make a quick hack". Ok, ok.
Don't forget to make this hack for boolean datatype as well: those
applications that not aware o
On 2-9-2019 13:16, Alex Peshkoff via Firebird-devel wrote:
On 02.09.2019 14:12, Dimitry Sibiryakov wrote:
02.09.2019 13:06, Alex Peshkoff via Firebird-devel wrote:
Suggested approach makes it possible to tune server to return data in
a form required by partcular client.
And (just in case) I
02.09.2019 13:27, Alex Peshkoff via Firebird-devel wrote:
May be OK for future versions.
..."but now we are going to make a quick hack". Ok, ok.
Don't forget to make this hack for boolean datatype as well: those applications that
not aware of this new datatype should get it as a string.
On 02.09.2019 14:22, Dimitry Sibiryakov wrote:
02.09.2019 13:16, Alex Peshkoff via Firebird-devel wrote:
How to make server always use offset (not timezone code) in selected
TS with TZ using coersion?
Usual way for data coercion: application just set desired data type
in metadata during fet
02.09.2019 13:16, Alex Peshkoff via Firebird-devel wrote:
How to make server always use offset (not timezone code) in selected TS with TZ using
coersion?
Usual way for data coercion: application just set desired data type in metadata during
fetch.
PS: I understand that it may be convenient
On 02.09.2019 14:12, Dimitry Sibiryakov wrote:
02.09.2019 13:06, Alex Peshkoff via Firebird-devel wrote:
Suggested approach makes it possible to tune server to return data in
a form required by partcular client.
And (just in case) I repeat: suggested approach duplicate data
coercion functio
02.09.2019 13:06, Alex Peshkoff via Firebird-devel wrote:
Suggested approach makes it possible to tune server to return data in a form required by
partcular client.
And (just in case) I repeat: suggested approach duplicate data coercion functionality
and is superfluous.
--
WBR, SD.
Fi
On 02.09.2019 13:53, Mark Rotteveel wrote:
On 2-9-2019 11:35, Alex Peshkoff via Firebird-devel wrote:
On 02.09.2019 11:25, Vlad Khorsun wrote:
30.08.2019 20:41, Mark Rotteveel wrote:
Hope Alex will answer this, below is my own understanding of
propositions.
Could you explicitly describe t
On 2-9-2019 11:35, Alex Peshkoff via Firebird-devel wrote:
On 02.09.2019 11:25, Vlad Khorsun wrote:
30.08.2019 20:41, Mark Rotteveel wrote:
Hope Alex will answer this, below is my own understanding of
propositions.
Could you explicitly describe the problem you think this solves, and
how y
On 02.09.2019 11:25, Vlad Khorsun wrote:
30.08.2019 20:41, Mark Rotteveel wrote:
Hope Alex will answer this, below is my own understanding of
propositions.
Could you explicitly describe the problem you think this solves, and
how your proposal solves it?
Hmm... the first paragraph at or
On 02.09.2019 11:17, Vlad Khorsun wrote:
30.08.2019 19:15, Adriano dos Santos Fernandes wrote:
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 sen
30.08.2019 20:41, Mark Rotteveel wrote:
Hope Alex will answer this, below is my own understanding of propositions.
Could you explicitly describe the problem you think this solves, and how your
proposal solves it?
Hmm... the first paragraph at original message explains it
BTW: This subj
30.08.2019 19:15, Adriano dos Santos Fernandes wrote:
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 u
On 31.08.2019 12:41, liviuslivius wrote:
>>About tools: isql supports all newer features
Who use isql, really?
I do. :)
I suppose only to confirm some bug. I cannot imagine that someone use
it by typing directly commands inside or looking at textual output if
gui tools have grids, filterin
>>About tools: isql supports all newer featuresWho use isql, really?I suppose
>>only to confirm some bug. I cannot imagine that someone use it by typing
>>directly commands inside or looking at textual output if gui tools have
>>grids, filtering...Regards,Karol Bieniaszewski
nullFirebird-Devel m
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 all
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 trou
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 exec
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
co
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 troub
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 becau
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 da
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 fo
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: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 variant
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
65 matches
Mail list logo
