1

Topic: Synchronization (replication) of DB Firebird

All greetings!
There is a project on Firebird 2.5, under the registration of the goods in shop.
Arose  at users - to see that happens on shops.
And since with the Internet normally problem, communication if also is, it often falls off and generally quality not so.
Thought of synchronization of bases through files - it is necessary to merge the information from trading points/warehouses in one principal basis where the user can already view all data, switching between warehouses (in the program it is possible to get some warehouses). Naturally given on each warehouse should fall in principal basis under ID this warehouse.
In principal basis can make out arrival of the goods which too should be preempted in shops.
also found pair of variants:
1) Through triggers to write down each change
2) By means of IBReplicator. Whether Here it only approaches for such situation? And how much I understood, it paid, whether I can put then it together  to users?
If someone can help, did such, or has a wide experience in Firebird and replications - I ask the help, about payment we can agree.

2

Re: Synchronization (replication) of DB Firebird

aidynchik;
IBReplicator precisely also creates triggers for guiding of dens of changes.
About licensing it at Dimitry Sibiryakov ask.

wrote:

If someone can help, did the such?

Here it is a lot of such. I and itself invented the bicycle. It even works till now.
If you will decide to go on a difficult way, i.e. independently to do  triggers and to apply changes on a principal DB ask, we help councils.

3

Re: Synchronization (replication) of DB Firebird

aidynchik;
I think at all replication it is made on  (at me including) but long this business... I 10 squeezed out all bugs of years.
Will buy probably ready more cheaply.

4

Re: Synchronization (replication) of DB Firebird

5

Re: Synchronization (replication) of DB Firebird

pastor;
We speak about the general principle when changes are transferred only. It approaches in most cases. There are certainly different variations, but it strongly depends on specificity of the task.

6

Re: Synchronization (replication) of DB Firebird

Evgenie wrote:

aidynchik;
Will buy probably ready more cheaply.

Yes, I also want to buy ready and what to buy? IBReplicator?

7

Re: Synchronization (replication) of DB Firebird

Denis wrote:

aidynchik;
About licensing it at Dimitry Sibiryakov ask.

How with it to communicate? Here at a forum there are no messages

8

Re: Synchronization (replication) of DB Firebird

aidynchik, to begin with it is necessary to interrogate properly the client what exactly it wants to see. Quite probably that in practice it will be possible to manage robot creation on sending of reports from remote bases or simply transfer of a certain data for the period.

9

Re: Synchronization (replication) of DB Firebird

Denis wrote:

aidynchik;
If you will decide to go on a difficult way, i.e. independently to do  triggers and to apply changes on a principal DB ask, we help councils.

Main point on ID what to make that they were not intersected? At each shop to set a range specific ID?
As you solved it.

10

Re: Synchronization (replication) of DB Firebird

MikeDD wrote:

aidynchik, to begin with it is necessary to interrogate properly the client what exactly it wants to see. Quite probably that in practice it will be possible to manage robot creation on sending of reports from remote bases or simply transfer of a certain data for the period.

Not all arranges, want is direct to see all

11

Re: Synchronization (replication) of DB Firebird

aidynchik wrote:

it is necessary to merge the information from trading points/warehouses in one principal basis, where
The user can already view all data, switching between warehouses

Here it is good to specify that such "users" and what your place in this system. If
It is uniform system and you in it the developer of all are one. If it is a duplicated product
And you the administrator of one of its copies - absolutely another.

aidynchik wrote:

a main point on ID what to make that they were not intersected?

There are three main methods: www.ibphoenix.com/ibpr_devel/fireswarm/documentation/dbdesign.html

12

Re: Synchronization (replication) of DB Firebird

aidynchik wrote:

a main point on ID what to make that they were not intersected? At each shop to set a range specific ID?
As you solved it.

Here there can be many decisions. It is possible to use as ID guid then they it is guaranteed not will to be intersected, but it is not so convenient. It is possible to use ranges.
Personally I used tables of code conversions. But at me generally different DB.

create table repl_transfer (
id not null, - id
sender_id bigint not null, - the identifier of a sending DB
source_id bigint not null, - a key in the initial table of a DB
dest_id bigint not null, - a key in the table the receiver
table_id bigint not null - the identifier of a card of correspondence of tables
);

Replication offline. The exchange goes through REST_API in format JSON

13

Re: Synchronization (replication) of DB Firebird

Dimitry Sibiryakov wrote:

If it is a duplicated product and you the administrator of one of its copies - absolutely another.

It is a duplicated product, and I the developer

14

Re: Synchronization (replication) of DB Firebird

If to use ranges, after all there are no warranties that ID does not pass for a range

15

Re: Synchronization (replication) of DB Firebird

aidynchik;
Well it looking what ranges to select. The type bigint can contain 1018 values.
If at you each range differs on 1012 probability that it will be overflowed almost zero

16

Re: Synchronization (replication) of DB Firebird

aidynchik wrote:

it is a duplicated product, and I the developer

Then you simply buy packs of licenses for a replicator at a discount and include their price in
The price of the product.

aidynchik wrote:

if to use ranges, after all there are no warranties that ID does not pass for a range

Ranges can be big enough if ID 64 bit, and a range, say, 48
The bit. But personally I recommend GUID.

17

Re: Synchronization (replication) of DB Firebird

aidynchik wrote:

that ID does not pass for a range

Is
Your client CERTAINLY should refuse passage through a range and should receive always from the server two ranges: leaking and following
"double buffering" and "Page flipping" - the same really bases!

18

Re: Synchronization (replication) of DB Firebird

Dimitry Sibiryakov wrote:

But personally I recommend GUID.

Typical error 90: sound the driver it seems Opti do not rise on the computer,  costs fineReader
yes, they occupied identical GUID

19

Re: Synchronization (replication) of DB Firebird

I, probably, am too primitive, to division of ranges did not grow, all somehow on-lapotnomu I think, about composite PK type (ID_Point, ID_In_Table)...

20

Re: Synchronization (replication) of DB Firebird

All thanks for councils!
The variant with IBReplicator does not approach me, I will do the bicycle. There will be questions - will write

21

Re: Synchronization (replication) of DB Firebird

Arioch wrote:

your client CERTAINLY should refuse passage through a range and should receive always from the server two ranges: leaking and following
"double buffering" and "Page flipping" - the same really bases!

If it is not difficult - it is possible this moment more in detail, I cannot tell that I  from god

22

Re: Synchronization (replication) of DB Firebird

Yes I actually already wrote all above
Any operation which should go without time delays, becomes a minimum in TWO  buffers
That you listen to music that cinema look that in  play
You have one buffer which went to operation (it is shown on the screen, plays earphones/columns etc.), and the second buffer with which fill (unpack mp3, build a scene of polygons...).
At that moment when it is time (the buffer is constructed And came to finish time the first buffer) switching becomes, buffers are interchanged the position (it is necessary to change only two pointers in places). Now the second buffer goes to operation (on the screen, columns, etc), and the first is cleared and starts to be filled with the data. Then they are again interchanged the position etc.
Earlier on "big-bellied" monitors switching of buffers  to V-Sync, a natural pause in operation of any a CRT-monitor so this adjustment was saved till now:-D
----------------------
Still at a special case - saving of any file, for example look as zip/7-zip/rar change archives. They do not kill an old file, they nearby create a temporary file and begin in it  new, corrected archive. And only if it turned out - then they do switching (renaming of two files, and AFTER successful renaming - removal of old archive).
Example of the school approach, with one buffer, - S.T.A.L.K.E.R. - if game  during saving (and it was frequent) at you old  ALREADY is not present, and new STILL is not present
-----------------
You ask about ranges ID - so in your case a range - the same buffer and too  to have two. On one you already you work, and another costs ready and waits for the instant switching-on in operation on exhaustion of the first, then do "switching of buffers" - the filled range merge on the server, and from the server receive a new pure range for tomorrow

23

Re: Synchronization (replication) of DB Firebird

Arioch wrote:

you ask about ranges ID - so in your case a range - the same buffer and too  to have two. On one you already you work, and another costs ready and waits for the instant switching-on in operation on exhaustion of the first, then do "switching of buffers" - the filled range merge on the server, and from the server receive a new pure range for tomorrow

Thanks, understood.

24

Re: Synchronization (replication) of DB Firebird

Old teddy bear;
Well to me this approach too becomes more, for example in it a point basically  from the server even if they  cannot year. I.e. the point can be sold separately, and a multi-point already then to sell to whom it is necessary.
But a minus of this approach - what to do if points slivajutsja/share, how historicity to observe? It is necessary to store somewhere history of communications different ID_Point? And than it differs from storage of stories of ranges? Somehow so.

25

Re: Synchronization (replication) of DB Firebird

Arioch wrote:

becomes

more
, it is pleasant, certainly