RE: Cascaded replication and initializing replicated sites

I had the same problems. We have many depots and one core (head office) server. The core server makes decisions which depot to forward a record to. We though informix would cascade inserts to the forwarding depot's. As you now, this is not possible. I had to write a small C daemon process that would update a row whenever a depot inserted a row at the core. The daemon uses a temp table to store rows that need to be cascaded to other depots. To insert rows into the temp table I had to define a stored procedure on the core box for every table I wanted to cacade. The daemon checks this table periodically and issues an update on the row specified in the stored proc. Not the most efficient but it works. As for recovery of crashed sites, well I'm still thinking about it. I don't have any kool solutions yet. Regards Silvester Valiente Informix DBA TNT Australia ---------- From: rob To: informix-list Subject: Cascaded replication and initializing replicated sites Date: Tuesday, 7 October 1997 10:58 <<File Attachment: CASCADED.TXT>> Hello reader, We are currently determining how to apply Informix Enterprise Replication. Currently wee foresee two problems. I would like to know: 1. if anybode has encountered the same problems 2. how these problems were solved First some background information: We are setting up an infrastructure which will consist of 500 remote sites connected to on central site through a low bandwidth, high latency . These 500 servers all are equipped with an Informix server and contains a database which holds a subset of the complete dataset stored at the central site. The following two problems are foreseen: (a) Initialisation of new sites/recovery of crashed sites. There are no standard features provided by Informix to initialise a new site based on the replication definitions. Are there any people that have encountered the same type op problem? (b) Cascaded replication It is not possible to implement cascaded replication, Which means that a tupels that are part of two replication definitions are always replicated correctly. Did anybody design a workaround for this. We could split up the 500 remote sites in multiple replication definition instead of one. Thanks in advance for your time and effort, Greetings, Rob