Yes, it's a bit mask. See the constants:
Shouldn't it be present in RDB$TYPES, as all other special numbers
?
I think that would be helpful.
I agree. ;)
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL Server,
Yes, it's a bit mask. See the constants:
Shouldn't it be present in RDB$TYPES, as all other
special numbers ?
I have them commented in my private sources for types.h, but the problem
is:
how do you want to handle them?
They need a bigint column, but the current column rdb$type is not
23.05.2014 8:14, Martijn Tonies (Upscene Productions) wrote:
- Any other suggestion?
Drop dialect 1 support.
Allow dialect 1 to have access to BIGINT fields.
--
WBR, SD.
--
Accelerate Dev Cycles with Automated
- Any other suggestion?
Drop dialect 1 support.
Allow dialect 1 to have access to BIGINT fields.
I don't have to work for this to happen, so I don't really have a say...
but the question that arises is why?
What are the reasons to continue to use dialect 1?
With regards,
Martijn
23.05.2014 10:24, Dimitry Sibiryakov wrote:
Allow dialect 1 to have access to BIGINT fields.
I have a feeling that Adriano already did that for v3.
Dmitry
--
Accelerate Dev Cycles with Automated Cross-Browser
E.g. our application still in dialect 1. It would be a huge job to
switch dialect 3.
On 2014.05.23. 8:41, Martijn Tonies (Upscene Productions) wrote:
- Any other suggestion?
Drop dialect 1 support.
Allow dialect 1 to have access to BIGINT fields.
I don't have to work for this to happen,
On 05/23/14 10:47, Dmitry Yemanov wrote:
23.05.2014 10:24, Dimitry Sibiryakov wrote:
Allow dialect 1 to have access to BIGINT fields.
I have a feeling that Adriano already did that for v3.
Yes, a few months ago.
W/o that change database triggers did not work correctly in dialect1
databases.
- Any other suggestion?
Drop dialect 1 support.
Allow dialect 1 to have access to BIGINT fields.
I don't have to work for this to happen, so I don't really have a say...
but the question that arises is why?
What are the reasons to continue to use dialect 1?
Because there are large
- Any other suggestion?
Drop dialect 1 support.
Allow dialect 1 to have access to BIGINT fields.
I don't have to work for this to happen, so I don't really have a say...
but the question that arises is why?
What are the reasons to continue to use dialect 1?
Because there are large
23.05.2014 8:41, Martijn Tonies (Upscene Productions) wrote:
but the question that arises is why?
What are the reasons to continue to use dialect 1?
Mathematic, for example. Standard behavior of division which dialect 3
supports is not
the best idea.
--
WBR, SD.
On 05/23/14 10:14, Martijn Tonies (Upscene Productions) wrote:
Yes, it's a bit mask. See the constants:
Shouldn't it be present in RDB$TYPES, as all other
special numbers ?
Definitely yes.
I have them commented in my private sources for types.h, but the problem
is:
how do you want to
On 05/23/14 13:43, Dimitry Sibiryakov wrote:
23.05.2014 11:29, Alex Peshkoff wrote:
It's not absolutely required to have bigint column - it's enough to
store bit number, which is less than 64.
It makes impossible to use JOIN to retrieve trigger's type via SQL query.
In this case
there
23.05.2014 11:54, Alex Peshkoff wrote:
Did you read that this is mask, not code? It's anyway impossible to join
directly, but with some functions - why not.
With mask it is possible to use LIST() and BIT_AND() to get list of triggers
with
actions. With bit number it won't work because of
On 05/23/14 13:59, Dimitry Sibiryakov wrote:
23.05.2014 11:54, Alex Peshkoff wrote:
Did you read that this is mask, not code? It's anyway impossible to join
directly, but with some functions - why not.
With mask it is possible to use LIST() and BIT_AND() to get list of
triggers with
On Fri, 23 May 2014 09:03:35 +0200, Paul Beach pbe...@ibphoenix.com
wrote:
- Any other suggestion?
Drop dialect 1 support.
Allow dialect 1 to have access to BIGINT fields.
I don't have to work for this to happen, so I don't really have a
say...
but the question that arises is why?
On Fri, 23 May 2014 11:43:56 +0200, Dimitry Sibiryakov s...@ibphoenix.com
wrote:
23.05.2014 11:29, Alex Peshkoff wrote:
It's not absolutely required to have bigint column - it's enough to
store bit number, which is less than 64.
It makes impossible to use JOIN to retrieve trigger's type
23.05.2014 12:43, Dimitry Sibiryakov wrote:
23.05.2014 11:29, Alex Peshkoff wrote:
It's not absolutely required to have bigint column - it's enough to
store bit number, which is less than 64.
It makes impossible to use JOIN to retrieve trigger's type via SQL query.
In this case
there
23.05.2014 12:48, Vlad Khorsun wrote:
This useless garbage is required for self-documenting
Self-documenting of what? Isn't list in header enough for this purpose?..
--
WBR, SD.
--
Accelerate Dev Cycles with
This useless garbage is required for self-documenting
Self-documenting of what? Isn't list in header enough for this purpose?..
No: Not everybody using firebird reads C-code.
Thomas
--
Diplom-Informatiker
Wielandstraße 14c • 23558 Lübeck
Tel +49 (22 25) 91 34 - 545 • Fax +49 (22 25) 91
On Fri, 23 May 2014 12:55:26 +0200, Dimitry Sibiryakov s...@ibphoenix.com
wrote:
23.05.2014 12:48, Vlad Khorsun wrote:
This useless garbage is required for self-documenting
Self-documenting of what? Isn't list in header enough for this
purpose?..
No, because looking in the source of
On 05/23/14 14:55, Dimitry Sibiryakov wrote:
23.05.2014 12:48, Vlad Khorsun wrote:
This useless garbage is required for self-documenting
Self-documenting of what? Isn't list in header enough for this purpose?..
Currently it's placed in a header, not distributed with binary packages.
If we
On Fri, 23 May 2014 09:03:35 +0200, Paul Beach pbe...@ibphoenix.com
wrote:
- Any other suggestion?
Drop dialect 1 support.
Allow dialect 1 to have access to BIGINT fields.
I don't have to work for this to happen, so I don't really have a
say...
but the question that arises is why?
What Thomas said. ;)
Also, I'm not quite getting how a bit mask can be a list of normal numbers,
but
this may be just me being confused.
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL,
23.05.2014 13:04, Martijn Tonies (Upscene Productions) wrote:
Also, I'm not quite getting how a bit mask can be a list of normal numbers,
but this may be just me being confused.
No, I also have no idea how to corellate data in RDB$TYPES with all the rest.
--
WBR, SD.
On Fri, 23 May 2014 13:02:32 +0200, Paul Beach pbe...@ibphoenix.com
wrote:
Sorry, but IMHO declaring dialect 1 as legacy and announcing dropping
of
support was already done with Interbase 6.0. The Interbase 6.0 Getting
Started Guide explicitly states that moving from Interbase 5 to
Interbase 6
On Fri, May 23, 2014 at 3:03 AM, Paul Beach pbe...@ibphoenix.com wrote:
- Any other suggestion?
Drop dialect 1 support.
Allow dialect 1 to have access to BIGINT fields.
For what little it's worth,
a) Dialect 1 did include 64bit integers at one time. VAX's had a native
64 bit
-Original Message-
From: Alex Peshkoff [mailto:peshk...@mail.ru]
Sent: Viernes, 23 de Mayo de 2014 6:05
On 05/23/14 13:59, Dimitry Sibiryakov wrote:
23.05.2014 11:54, Alex Peshkoff wrote:
Did you read that this is mask, not code? It's anyway
impossible to join
directly, but
27 matches
Mail list logo
