Em 6/3/2012 03:46, Alex Peshkoff escreveu:
>
> And taking into an account that we do not support ODS< 12 in current
> engine - do we need to keep support of old BLR versions? I see 2 ways
> for old BLR to arrive in ODS12 database. First of all - when old
> database is restored. May be we should le
Having started this discussion by agreeing with Claudio, now let me suggest
that I was probably wrong. I'll think about it a bit more, but finding a
way of extending blr compatibly seems like a much better idea. That lets
old databases continue to work and avoids the whole discussion of what
other
06.03.2012 21:27, Leyne, Sean wrote:
> select 2 * 1.001 from rdb$database => 2.000
This is just a display artefact. Precision of double is enough to keep 11
significant
digits.
--
SY, SD.
--
Keep Your D
> 06.03.2012 20:54, Adriano dos Santos Fernandes wrote:
> > It will be 0.333... (up to the maximum NUMBER scale precision).
> >
> > The thing is that for operations like addition, subtraction, NUMBER
> > will work like NUMERIC (i.e., it's results are more precise than DOUBLE).
>
>In this cas
> I think the solution (not hacks with dialects) to this problem is not
> difficult.
>
> Firebird don't need to change the way it does numeric/decimal arithmetics
> and introduce another dialect leaving current and previous one for decades.
> Firebird is right on the way it does.
>
> So, add a
06.03.2012 20:54, Adriano dos Santos Fernandes wrote:
> It will be 0.333... (up to the maximum NUMBER scale precision).
>
> The thing is that for operations like addition, subtraction, NUMBER will
> work like NUMERIC (i.e., it's results are more precise than DOUBLE).
In this case much easier is
On 06/03/2012 16:37, Dimitry Sibiryakov wrote:
> 06.03.2012 20:31, Adriano dos Santos Fernandes wrote:
>> So, add a new datatype NUMBER(x, y) who does BCD arithmetics like it's
>> done in Oracle.
> What this data type will change? What will be result of 1/3 for this data
> type? If 0,
> it won
06.03.2012 20:31, Adriano dos Santos Fernandes wrote:
> So, add a new datatype NUMBER(x, y) who does BCD arithmetics like it's
> done in Oracle.
What this data type will change? What will be result of 1/3 for this data
type? If 0,
it won't be different from DECIMAL. If 0.(3), how much "3" wil
On 06/03/2012 16:01, Leyne, Sean wrote:
> This is why BroadView hasn't made the move from Dialect 1. The numeric rules
> imposed by Dialect 3 would have required a huge amount of re-coding and
> testing to ensure that our calculations/reports generated the expected
> results.
>
> BTW, unless I
> -Original Message-
> From: Claudio Valderrama C. [mailto:cva...@usa.net]
> Sent: Tuesday, March 06, 2012 6:29 AM
>
> > -Original Message-
> > From: Alex Peshkoff [mailto:peshk...@mail.ru]
> > Sent: Martes, 06 de Marzo de 2012 8:06
> >
> > Also want to agree, but I remember there
06.03.2012 10:30, Alex Peshkoff wrote:
> On 03/06/12 13:06, Dimitry Sibiryakov wrote:
>> > 06.03.2012 10:03, Alex Peshkoff wrote:
>>> >> Does it mean that in dialect 1 we keep old limits like number of
>>> >> streams?
>> > It means that you keep old limits for applications which use old B
06.03.2012 10:55, Kjell Rilbe wrote:
> I'm sure there will be objections. I'd say the world moves
> forward - if you don't want it to, that's your problem - live with it!
> Meaning: if you really want to stay at dialect 1, then fine with me, but
> then live with the implications, e.g. staying with
> -Original Message-
> From: Alex Peshkoff [mailto:peshk...@mail.ru]
> Sent: Martes, 06 de Marzo de 2012 8:06
>
> Also want to agree, but I remember there were some real reasons
> (unfortunately do not remember them) making people stay with dialect1.
> May be somebody remembers that reaso
06.03.2012 15:05, Alex Peshkoff wrote:
> Also want to agree, but I remember there were some real reasons
> (unfortunately do not remember them) making people stay with dialect1.
> May be somebody remembers that reasons?
Lack of precisions bigger than 18 in NUMERIC/DECIMAL and, even more
importan
Hello, can someone comment on the usefulness of this flag, please?
class dsql_req : public pool_alloc
{
static const unsigned FLAG_EMBEDDED = 0x02;
It's only used in dsql.cpp, inside DSQL_execute()
if ((SSHORT) in_msg_type == -1)
request->
On 03/06/12 14:47, Adriano dos Santos Fernandes wrote:
> On 06/03/2012 06:55, Kjell Rilbe wrote:
>> Meaning: if you really want to stay at dialect 1, then fine with me, but
>> then live with the implications, e.g. staying with an old version of FB.
>>
>>
> Completely agreed.
Also want to agree, b
On 03/06/12 14:47, Adriano dos Santos Fernandes wrote:
> On 06/03/2012 07:14, Claudio Valderrama C. wrote:
>>> -Original Message-
>>> From: Kjell Rilbe [mailto:kjell.ri...@datadia.se]
>>> Sent: Martes, 06 de Marzo de 2012 6:55
Isn't it about time to drop support for dialect 1?
>>> Yes
On 06/03/2012 06:55, Kjell Rilbe wrote:
> Meaning: if you really want to stay at dialect 1, then fine with me, but
> then live with the implications, e.g. staying with an old version of FB.
>
>
Completely agreed.
Adriano
--
On 06/03/2012 07:14, Claudio Valderrama C. wrote:
>> -Original Message-
>> From: Kjell Rilbe [mailto:kjell.ri...@datadia.se]
>> Sent: Martes, 06 de Marzo de 2012 6:55
>>> Isn't it about time to drop support for dialect 1?
>> Yes. But I'm sure there will be objections. I'd say the world move
Den 2012-03-06 11:07 skrev Mark Rotteveel såhär:
> On Tue, 6 Mar 2012 07:14:44 -0300, "Claudio Valderrama C."
>
> wrote:
>>> -Original Message-
>>> From: Kjell Rilbe [mailto:kjell.ri...@datadia.se]
>>> Sent: Martes, 06 de Marzo de 2012 6:55
Isn't it about time to drop support for dial
On Tue, 6 Mar 2012 07:14:44 -0300, "Claudio Valderrama C."
wrote:
>> -Original Message-
>> From: Kjell Rilbe [mailto:kjell.ri...@datadia.se]
>> Sent: Martes, 06 de Marzo de 2012 6:55
>> >
>> > Isn't it about time to drop support for dialect 1?
>> Yes. But I'm sure there will be objections
> -Original Message-
> From: Alex Peshkoff [mailto:peshk...@mail.ru]
> Sent: Martes, 06 de Marzo de 2012 3:32
>
> On 03/06/12 02:31, Claudio Valderrama C. wrote:
> > Hello, I need a backup of a real database for testing my
> changes to FB.
> > A few rows of data would be enough.
>
> Da
> -Original Message-
> From: Kjell Rilbe [mailto:kjell.ri...@datadia.se]
> Sent: Martes, 06 de Marzo de 2012 6:55
> >
> > Isn't it about time to drop support for dialect 1?
> Yes. But I'm sure there will be objections. I'd say the world moves
> forward - if you don't want it to, that's yo
Den 2012-03-06 10:22 skrev Mark Rotteveel såhär:
> On Tue, 06 Mar 2012 13:03:04 +0400, Alex Peshkoff
> wrote:
>> I do not speak about removing BLR API, but for how long are we going to
>> support old versions of BLR?
>> Is it about supporting dialect 1?
>> Does it mean that in dialect 1 we keep old
On Tue, 06 Mar 2012 13:03:04 +0400, Alex Peshkoff
wrote:
> I do not speak about removing BLR API, but for how long are we going to
> support old versions of BLR?
> Is it about supporting dialect 1?
> Does it mean that in dialect 1 we keep old limits like number of
streams?
Isn't it about time to
On 03/06/12 13:06, Dimitry Sibiryakov wrote:
> 06.03.2012 10:03, Alex Peshkoff wrote:
>> Does it mean that in dialect 1 we keep old limits like number of streams?
>It means that you keep old limits for applications which use old BLR
> dialects.
>
But it's the same:
dsql:
if (dsqlScratch
06.03.2012 10:03, Alex Peshkoff wrote:
> Does it mean that in dialect 1 we keep old limits like number of streams?
It means that you keep old limits for applications which use old BLR
dialects.
--
SY, SD.
--
Keep
On 03/06/12 12:42, Dmitry Yemanov wrote:
> 06.03.2012 10:46, Alex Peshkoff wrote:
>
>> And taking into an account that we do not support ODS< 12 in current
>> engine - do we need to keep support of old BLR versions? I see 2 ways
>> for old BLR to arrive in ODS12 database. First of all - when old
06.03.2012 10:46, Alex Peshkoff wrote:
> And taking into an account that we do not support ODS< 12 in current
> engine - do we need to keep support of old BLR versions? I see 2 ways
> for old BLR to arrive in ODS12 database. First of all - when old
> database is restored. May be we should learn g
29 matches
Mail list logo
