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
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
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
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,
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
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
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
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 ?
>>>
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
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
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
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
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
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
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
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
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 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
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
19 matches
Mail list logo
