14.11.2019 23:19, Clyde Eisenbeis cte...@gmail.com [firebird-support] wrote:
> The previous comments indicate that Firebird is Litle Endian.
It doesn't matter because Firebird client deliver length of VARCHAR in
native endiannes
and for the rest there are API functions to convert
For a minor clarification. In the electronics world, we specify the
sequence of multiple bytes with the word "Endian".
Assume the hex number is 0x1A2B. For Big Endian, the 0x1A is first. For
Little Endian, the 0x2B is first. The previous comments indicate that
Firebird is Litle Endian.
(For
14.11.2019 20:29, Mark Rotteveel m...@lawinegevaar.nl [firebird-support] wrote:
> And that part of the documentation is unfortunately wrong (although I'm
> not sure why the language reference even cares to describe such an
> implementation detail).
This documentation is actively corrected and
14.11.2019 20:29, Mark Rotteveel m...@lawinegevaar.nl [firebird-support] wrote:
> Actually Dimitry, Steve was quoting from the Firebird 2.5 Language
> Reference:
>
On 14-11-2019 19:02, Dimitry Sibiryakov s...@ibphoenix.com
[firebird-support] wrote:
> 14.11.2019 18:01, blackfalconsoftw...@outlook.com [firebird-support] wrote:
>> However, the PDF language manual I have for version 2.5 does in fact state
>> the following...
>>
>>
>> "A fixed-length character
On 14-11-2019 18:01, blackfalconsoftw...@outlook.com [firebird-support]
wrote:
> I found what we have been arguing over in the Firebird 2.5 Language
> Reference Manual since I don't seem to have the one for version 3.0. I
> looked for it at the Firebird site but it does not appear to be
14.11.2019 18:01, blackfalconsoftw...@outlook.com [firebird-support] wrote:
> However, the PDF language manual I have for version 2.5 does in fact state
> the following...
>
>
> "A fixed-length character data type. When its data is displayed, trailing
> spaces are added
> to the string up to
I found what we have been arguing over in the Firebird 2.5 Language Reference
Manual since I don't seem to have the one for version 3.0. I looked for it at
the Firebird site but it does not appear to be listed...
>>>
CHAR DATA TYPE (CHAR(n), CHARACTER(n))
On 2019-11-13 17:37, blackfalconsoftw...@outlook.com [firebird-support]
wrote:
> Your statement, which may be true, does not sit well with a previous
> statement that states that a VARCHAR field of 1000 characters is
> stored in the table with 1000 characters.
>
> Your statement is suggesting a
14.11.2019 17:08, blackfalconsoftw...@outlook.com [firebird-support] wrote:
> The links provided to me had the information on the IB-Experts web site...
I didn't see who provided you any link, but here is right one:
https://firebirdsql.org/en/reference-manuals/
At the bottom of this page
The links provided to me had the information on the IB-Experts web site...
If there information is incorrect, you should contact them to have it
corrected...
Steve Naidamast
Sr. Software Engineer
On 2019-11-13 18:42, blackfalconsoftw...@outlook.com [firebird-support]
wrote:
> Here is the link to the definition of CHAR and VARCHAR field
> definitions from the IB-Experts site...
>
>
> https://www.ibexpert.net/ibe/index.php?n=Doc.CHAR
> https://www.ibexpert.net/ibe/index.php?n=Doc.CHAR
>
13.11.2019 18:42, blackfalconsoftw...@outlook.com [firebird-support] wrote:
> So my understanding of how the VARCHAR field works is correct and what I have
> stated earlier.
Your understanding is wrong and either IB Expert site is wrong as well or
you misread it.
Yest remember: CHAR -
Here is the link to the definition of CHAR and VARCHAR field definitions from
the IB-Experts site...
https://www.ibexpert.net/ibe/index.php?n=Doc.CHAR
https://www.ibexpert.net/ibe/index.php?n=Doc.CHAR
It defines the storing of CHAR and VARCHAR in the same manner, though the
VARCHAR data
13.11.2019 17:37, blackfalconsoftw...@outlook.com [firebird-support] wrote:
> Your statement is suggesting a null length (until the field is updated) with
> two bytes for
> an actual length, which is how VARCHAR fields work in all other databases to
> my
> knowledge. Otherwise, to follow the
Your statement, which may be true, does not sit well with a previous statement
that states that a VARCHAR field of 1000 characters is stored in the table with
1000 characters.
Your statement is suggesting a null length (until the field is updated) with
two bytes for an actual length, which
13.11.2019 16:09, blackfalconsoftw...@outlook.com [firebird-support] wrote:
> If a VARCHAR field is defined for 1000 characters and it is stored in the
> table at a 1000
> character length than there is no purpose to an actual VARCHAR field
> definition.
There is. I addition to 1000
Though I cannot dispute what you are saying, to me it does not make much sense.
If a VARCHAR field is defined for 1000 characters and it is stored in the
table at a 1000 character length than there is no purpose to an actual VARCHAR
field definition.
VARCHAR fields have always been
18 matches
Mail list logo
