On 3/2/19 8:18 PM, Mark Rotteveel wrote:
On 2-3-2019 13:45, Alex Peshkoff via Firebird-devel wrote:
On 3/2/19 3:24 PM, Mark Rotteveel wrote:
2. Usage of the term Linux AMD64 might be confusing for people,
assuming it doesn't work on their Intel processor.
We may want to consider renaming to x
Faced the following problem when working with Firebird 4.0 via IBExpert.
Trying to execute the following SQL query.
SELECT current_time FROM $RDB$DATABASE
SQLCODE: -902
GDSCODE: 335545167
Unsuccessful execution caused by a system error that precludes successful
execution of subsequent statem
On 4-3-2019 09:25, Alex Peshkoff via Firebird-devel wrote:
On 3/2/19 8:18 PM, Mark Rotteveel wrote:
On 2-3-2019 13:45, Alex Peshkoff via Firebird-devel wrote:
On 3/2/19 3:24 PM, Mark Rotteveel wrote:
2. Usage of the term Linux AMD64 might be confusing for people,
assuming it doesn't work on th
I noticed when using native connections when experimenting with time
zone support in Jaybird, that the buffer returned by the client for a
TIMESTAMP WITH TIME ZONE will be 12 bytes, even though it is a TIMESTAMP
(8 bytes) + short (2 bytes) for the id (possibly due to padding).
For the network
On 3/4/19 12:53 PM, Mark Rotteveel wrote:
I noticed when using native connections when experimenting with time
zone support in Jaybird, that the buffer returned by the client for a
TIMESTAMP WITH TIME ZONE will be 12 bytes, even though it is a
TIMESTAMP (8 bytes) + short (2 bytes) for the id (p
04.03.2019 14:40, Alex Peshkoff wrote:
Mark, I'm not 100% sure for TZ id but in all other known to me cases
16-bit integers are sent over the wire in 32-bit network format. I
suppose you should read that id as any other 16-bit value.
Absolutely correct.
Dmitry
Firebird-Devel mailing list
04.03.2019 11:16, Simonov Denis via Firebird-devel wrote:
Faced the following problem when working with Firebird 4.0 via IBExpert.
Trying to execute the following SQL query.
SELECT current_time FROM $RDB$DATABASE
SQLCODE: -902
GDSCODE: 335545167
Unsuccessful execution caused by a system error
On 3/4/19 2:57 PM, Vlad Khorsun wrote:
04.03.2019 11:16, Simonov Denis via Firebird-devel wrote:
Faced the following problem when working with Firebird 4.0 via IBExpert.
Trying to execute the following SQL query.
SELECT current_time FROM $RDB$DATABASE
SQLCODE: -902
GDSCODE: 335545167
Unsucce
04.03.2019 14:01, Alex Peshkoff via Firebird-devel wrote:
On 3/4/19 2:57 PM, Vlad Khorsun wrote:
I have additional question: is it true that fbclient now depends on ICU ?
As fas as I know - not. At least IntlManager.cpp is placed in src/jrd, which is
used only in engine.
Client is using o
On 4-3-2019 12:48, Dmitry Yemanov wrote:
04.03.2019 14:40, Alex Peshkoff wrote:
Mark, I'm not 100% sure for TZ id but in all other known to me cases
16-bit integers are sent over the wire in 32-bit network format. I
suppose you should read that id as any other 16-bit value.
Absolutely correc
On 3/4/19 3:15 PM, Vlad Khorsun wrote:
04.03.2019 14:01, Alex Peshkoff via Firebird-devel wrote:
On 3/4/19 2:57 PM, Vlad Khorsun wrote:
I have additional question: is it true that fbclient now depends
on ICU ?
As fas as I know - not. At least IntlManager.cpp is placed in
src/jrd, which i
04.03.2019 14:57, Alex Peshkoff via Firebird-devel wrote:
May be taht makes sense - in a case when we start to work with TZ-related data we should
already have connection with any engine.
In this case IAttachment must be a parameter for util functions to know which server to
ask for conversi
On 04/03/2019 10:57, Alex Peshkoff via Firebird-devel wrote:
> On 3/4/19 3:15 PM, Vlad Khorsun wrote:
>> 04.03.2019 14:01, Alex Peshkoff via Firebird-devel wrote:
>>> On 3/4/19 2:57 PM, Vlad Khorsun wrote:
>>
I have additional question: is it true that fbclient now depends
on ICU ?
>>>
On 04/03/2019 14:08, Adriano dos Santos Fernandes wrote:
I suppose that any "real" dependency here is to transform TZ-id to
string and vice-versa.
As that is present in IUtil, changing that to require the server (or
transform IDs to string in data structures and wire protocol) would be a
signifi
On 3/4/19 5:08 PM, Adriano dos Santos Fernandes wrote:
I suppose that any "real" dependency here is to transform TZ-id to
string and vice-versa.
As that is present in IUtil, changing that to require the server (or
transform IDs to string in data structures and wire protocol) would be a
signific
On 4-3-2019 10:53, Mark Rotteveel wrote:
I noticed when using native connections when experimenting with time
zone support in Jaybird, that the buffer returned by the client for a
TIMESTAMP WITH TIME ZONE will be 12 bytes, even though it is a TIMESTAMP
(8 bytes) + short (2 bytes) for the id (po
On 04/03/2019 17:01, Mark Rotteveel wrote:
Interesting bit of information: in the wire protocol, the time zone id
is encoded as a signed short, which results in for example Europe/Moscow
(id = 65064 or 0xFE28) being encoded as bytes 0xFE28 due to
sign-extension, in little-endian native, the
On 2019-03-04 19:46, Lester Caine wrote:
On 04/03/2019 17:01, Mark Rotteveel wrote:
Interesting bit of information: in the wire protocol, the time zone id
is encoded as a signed short, which results in for example
Europe/Moscow (id = 65064 or 0xFE28) being encoded as bytes 0xFE28
due to si
On 04/03/2019 20:01, Mark Rotteveel wrote:
And that is not the point of this thread. I know it is a 16 bit unsigned
short inside Firebird, and I know how the value works.
My question is about the **encoding** in the data buffer obtained from
the native client. I want to avoid incorrectly imple
02.03.2019 14:25, Mark Rotteveel wrote:
On 28-12-2018 17:44, Mark Rotteveel wrote:
It looks like database creation in Firebird 4 is slower (about 50%) compared to 3.0.4. On my system, creating a database in
Firebird 3.0.4 (through org.firebirdsql.management.FBManager) takes roughly 200ms, while
20 matches
Mail list logo
