Subject | Re: [ib-support] Why fbembed.dll ? |
---|---|
Author | Dimitry Sibiryakov |
Post date | 2003-05-12T06:07:52Z |
On 8 May 2003 at 15:29, Boguslaw Brandys wrote:
address" setting but definitelly not me.
complicated thing, but application-dependent one is much simplier and
you may be able to implement it.
Usually it is based on "one central office - many branch offices"
ideology and driven by set of rules like this: "this kind of data
must be entered in central office only"; "these tables are one-way
replicated, those - two-way, others are local"; "office staff can
modify only records entered in this office" and so on.
Then a set of triggers for every replicated table, composite
primary keys (filialNo;autoInc) and a couple of utilites - one for
making a new delta packet to send to a remote office and another to
merge incoming delta packet into local DB.
The worst problems is conflicts' resolving and duplicates
eliminating. They are common for all DBs but especially annoying in
distributed ones.
SY, Dimitry Sibiryakov.
>Maybe I misreported something, but is a simple solution (like switchNot (yet?). I guess somebody can implement something like "Bind
>in firebird.conf) to forbid remote outside connection (from Internet)
>to such server ?
address" setting but definitelly not me.
>> Then I'd choose replication. Well-implemented replication can useNot any I'm aware of. Universal replication engine is a quite
>> E-mail and even snake-mail.
>
>But any freeware replication engine ?
complicated thing, but application-dependent one is much simplier and
you may be able to implement it.
Usually it is based on "one central office - many branch offices"
ideology and driven by set of rules like this: "this kind of data
must be entered in central office only"; "these tables are one-way
replicated, those - two-way, others are local"; "office staff can
modify only records entered in this office" and so on.
Then a set of triggers for every replicated table, composite
primary keys (filialNo;autoInc) and a couple of utilites - one for
making a new delta packet to send to a remote office and another to
merge incoming delta packet into local DB.
The worst problems is conflicts' resolving and duplicates
eliminating. They are common for all DBs but especially annoying in
distributed ones.
SY, Dimitry Sibiryakov.