On 3/9/07 12:16 PM, "Thorsten Hohage" <[EMAIL PROTECTED]> wrote:
Hi Thorsten, >> And here main question we have: >> >> Does laptops should have >> a) the whole snapshoot of server db ? > > sometimes yes - it seems that especially germans tend to carry the > whole 10GB DB with them, but ... > >> b) or its part? > > yes - THIS is in most cases (system I build) used. But part often > means depend on context i.e. a query what should be replicated (where > staff_district = 'Hamburg') and it depends on the table, too. So > articles complete, customers only from the district, help desk-tables > none. Right, each client should have set of own FILTERs. And as Bart point this also help with security (e.g. Employers should not see what Managers can). > Additional one further remark > >>> Changes are synced when network is available. > > perhaps not only when network is available. There are still > situations where syncing should be done by media transfer, i.e. USB- > Stick, CD, ... i.e. imagine a expedition where the entered data must > be synced and NO or better NO cheap enough network is enable ----------------- > And I want to add two more and really important topics! There must be > a solution for generating unique-keys, too - something like satellite- > id + table-unique-id to be able to sync data - enter new data on each > system - re-sync - enter other new data ... could be tricky, really > tricky. Right. In MS SQL they use GUID for this. Ivan like this solution the most as I see :-) So our first step then should be adding this field type into Valentina. > We used a system with a central serial table with pre-generated > serials and an id for what satellite this id is. These serials are > replicated, too and so every system gets its set of serials. Using > triggers to request a serial when a record is generated. But of > course there are several more concept on how to handle serials in a > distributed system Yes, pre-generated serials also used often. Although agree, this require some special job on both computers to prepare them for replications. Annoying. > The same problem is regarding deletion of data. Satellite_1 and > Satellite_2 get some contacts in the same time. Now Satellite_1 > deletes a contact and Satellite_2 changes this contact later in time, > then Satellite_1 deletes it. Satellite_1 syncs his data to server, > later Satellite_2 syncs too and the contact is back. Next time > Satellite_1 syncs with the server he gets the deleted contact back. > > Other scenario: Satellite_1 and Satellite_2 gets both contact data, > but Satellite_2 get the invoices, too. Satellite_1 doesn't see any > invoices and deletes the contact, what happened with the joined data > that are still on Satellite_2. > > Of course some of these issues must be handled by application (better > system) logic, but there must be propitiate options in the database > to configure these rules. These are "CONFLICTS". In the most hard cases human manual task required, like when we have conflicts workings with CVS. -- Best regards, Ruslan Zasukhin VP Engineering and New Technology Paradigma Software, Inc Valentina - Joining Worlds of Information http://www.paradigmasoft.com [I feel the need: the need for speed] _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
