18.05.2021 23:42, Adriano dos Santos Fernandes wrote:
UDF was been deprecated in FB 4.
Could we remove them from master for v5?
I have the same question about dialect 1 and multi-file databases (which already were
supposed to be removed in 4.0).
--
WBR, SD.
Firebird-Devel mailing list
Hi!
UDF was been deprecated in FB 4.
Could we remove them from master for v5?
Also QLI, I believe nobody uses it and there should be no good reason to
maintain it.
I know TCS uses it, so it should be changed.
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.n
Hi Dimitry,
unfortunately, this is not that case.
It seems this happen when we read data from an another database and
insert/update into the master one.
This is an execute block running for execute statement on external and the
target table has the trigger which increases the generator
Both gene
Settings written to database only, not stored outside.
Then there is not something like the „defaults”.
There many other scenarions not only 1/0.
It can be date and time stored into generator values and more…
I think about replicating generators at all.
regards,
Karol Bieniaszewski
Od: Dimitry S
18.05.2021 16:22, liviuslivius wrote:
But such replica cannot became "master" database if master is
broken/unavailable?
Why? Values of generators used as flags are usually not important and are reset to
defaults by application after promoting as if primary server has been suddenly aborted
But such replica cannot became "master" database if master is
broken/unavailable?Regards,Karol Bieniaszewski
Oryginalna wiadomość Od: Dimitry Sibiryakov
Data: 18.05.2021 16:03 (GMT+01:00) Do: For discussion
among Firebird Developers Temat: Re:
[Firebird-devel] ODP: Replicat
18.05.2021 15:33, Karol Bieniaszewski wrote:
I as as we use genertors also as settings. E.g. we change it from 1 to 0 and
back.
And in procedures or triggers we check for value in generator if it is 1 (on)
or 0 (off).
This usage is no-go in master-slave setting because the procedures and tr
18.05.2021 14:45, Omacht András wrote:
We have very complex and long running tests.
We ran the simpliest, which creates hundreds of domains, tables, stored
procedures, views, triggers and inserting thousands data into tables.
Almost everything is ok with replication, we only have two generators
>> Sorry for the blind noise.
It is not noise.
Is there a way to configure replication to always replicate generator change?
I as as we use genertors also as settings. E.g. we change it from 1 to 0 and
back.
And in procedures or triggers we check for value in generator if it is 1 (on)
or 0 (o
On 5/18/21 3:57 PM, Norbert Saint Georges wrote:
Hello,
I just compiled Firebird via git and he pulls me out the version
Firebird 5.0.0.40-Initial.amd64 .
Normal?
Yes.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Hello,
I just compiled Firebird via git and he pulls me out the version
Firebird 5.0.0.40-Initial.amd64 .
Normal?
--
Norbert Saint Georges
http://tetrasys.fi
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Dmitry, sorry, you are right, I oversimplified the case.
It works well If I create primary key.
We have very complex and long running tests.
We ran the simpliest, which creates hundreds of domains, tables, stored
procedures, views, triggers and inserting thousands data into tables.
Almost everyt
18.05.2021 13:45, Dmitry Yemanov wrote:
What you should get is a "Table TMP_TABLE has no unique key" error while committing the
UPDATE statement.
If reporting of replication errors had been enabled by default...
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sou
18.05.2021 13:47, Omacht András wrote:
It looks like when I do update and commit then the generator's value is not
syncronized.
As Dmitry wrote above it is not synchronized because of replication error.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge
Just one more info.
After this if I do
insert into TMP_TABLE (VC) values ('C');
commit;
the generator value is ok again. Both in master and replica has 3.
It looks like when I do update and commit then the generator's value is not
syncronized.
András
-Original Message-
From: Omacht
18.05.2021 14:36, Omacht András wrote:
Ok, let's see the following example:
Master:
CREATE SEQUENCE TMP_GEN_2;
commit;
CREATE TABLE TMP_TABLE (
VC VARCHAR(10)
);
commit;
CREATE OR ALTER TRIGGER TMP_TABLE_BIU0 FOR TMP_TABLE
ACTIVE BEFORE INSERT OR UPDATE POSITION 0
as
declare variable du
Ok, let's see the following example:
Master:
CREATE SEQUENCE TMP_GEN_2;
commit;
CREATE TABLE TMP_TABLE (
VC VARCHAR(10)
);
commit;
CREATE OR ALTER TRIGGER TMP_TABLE_BIU0 FOR TMP_TABLE
ACTIVE BEFORE INSERT OR UPDATE POSITION 0
as
declare variable dummy integer;
begin
dummy = gen_id(tmp_gen
18.05.2021 13:20, Omacht András wrote:
I commited, as shown in my example.
Transaction also must contain some DML. Without it replication of generator
is pointless.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
18.05.2021 13:52, Omacht András wrote:
FB4 - 4.0.0.2489
We tried the following in both (sync, async) modes:
Master:
CREATE SEQUENCE TMP_GEN_1;
commit;
(The sequence was created fine in replicas.)
Master:
select gen_id(tmp_gen_1, 1) from rdb$database;
-- Result: 1 - OK
commit;
select ge
Hi Dimitry,
I commited, as shown in my example.
Master:
select gen_id(tmp_gen_1, 1) from rdb$database;
-- Result: 1 - OK
commit;
(In my opinion, replication should work for rollback anyway.)
CÉGÜNK A LIBRA CSOPORT TAGJA
OMACHT ANDRÁS
fejlesztési igazgató
LIBRA Szoftver Zrt.
1113 Budapest,
18.05.2021 12:52, Omacht András wrote:
Can someone confirm if this is a bug?
No, this is by design. You must commit transaction that changed sequence on
master side.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
;
-- Result: 1 - OK
Replica:
select gen_id(tmp_gen_1, 0) from rdb$database;
-- Result: 0 - This should be 1.
Can someone confirm if this is a bug?
András
__ Information from ESET Mail Security, version of virus signature
database 23314 (20210518) __
The message was checked by
;
-- Result: 1 - OK
Replica:
select gen_id(tmp_gen_1, 0) from rdb$database;
-- Result: 0 - This should be 1.
Can someone confirm if this is a bug?
András
__ Information from ESET Mail Security, version of virus signature
database 23314 (20210518) __
The message was checked by
18.05.2021 12:38, Nils Bödeker wrote:
These settings are not necessary for synchronous-only setup. Moreover, removing
them will actually cause your issue to disappear ;-) But this way we'd never
find this bug ;-)
So that I get it right.
There is no bug in the synchronous replications.
The
Hello Dmitry,
> These settings are not necessary for synchronous-only setup. Moreover,
> removing them will actually cause your issue to disappear ;-) But this way
> we'd never find this bug ;-)
So that I get it right.
There is no bug in the synchronous replications.
There is an bug in the as
25 matches
Mail list logo
