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
On 23-5-2014 17:55, Ann Harrison wrote:
b) When your database company forces you to rewrite your application
(losing arithmetic precision in the process) for the convenience of the
company's developers, it's time to consider the cost of moving to a
different database.
I think that is a cop
24.05.2014 2:28, Claudio Valderrama C. wrote:
We have
BIN_SHL
BIN_SHR
for shifting bits.
Oh, indeed. Stupid me... :(
--
WBR, SD.
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
-Original Message-
From: Dimitry Sibiryakov [mailto:s...@ibphoenix.com]
Sent: Sábado, 24 de Mayo de 2014 3:13
24.05.2014 2:28, Claudio Valderrama C. wrote:
We have
BIN_SHL
BIN_SHR
for shifting bits.
Oh, indeed. Stupid me... :(
BTW, I wonder if we documented this:
SQL
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
On 22-05-2014 09:32, Martijn Tonies (Upscene Productions) wrote:
Hi all,
How can I get the type of the DDL trigger (eg “create procedure”)?
I’ve noticed RDB$TYPES doesn’t hold any values for it and using
ANY, it seems like it’s a bit mask.
Any clues?
Yes, it's a bit mask. See the
Hello Adriano,
Thanks, I've browsed through the source a bit, but couldn't find these.
What file are these in?
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and
On 22-05-2014 12:13, Martijn Tonies (Upscene Productions) wrote:
Hello Adriano,
Thanks, I've browsed through the source a bit, but couldn't find these.
What file are these in?
src/jrd/constants.h
Adriano
--
Yes, it's a bit mask. See the constants:
Shouldn't it be present in RDB$TYPES, as all other special numbers ?
Regards,
Vlad
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run
On Thu, 22 May 2014 18:24:12 +0300, Vlad Khorsun
hv...@users.sourceforge.net wrote:
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.
Mark
-Original Message-
From: Vlad Khorsun [mailto:hv...@users.sourceforge.net]
Sent: Jueves, 22 de Mayo de 2014 11:24
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
37 matches
Mail list logo
