Replicate not starting

Good day I have Replicates that's inactive and when i try to start them it gives invalid replicate change. It is not on all servers just 2 or 3 servers but on other servers it's active. I'm I missing something ------------------------------ Jaco Loots ------------------------------

Hi Jaco, assuming this is the ball we've dropped elsewhere, sorry for that?! As for those replicate states, there might be an explanation for this confusion: First of all there's a distinction internally between 'replicate state' and 'participant state', and it's not clear, on the face of it, which one you're getting from "cdr list replicate"; and not only is it not clear if generally rep_state OR part_state, it even can be either of them. The (internal) rule: if rep_state is Active show part_state, else show rep_state -- making things any more clear? ;-) The actual truth is in syscdr repdef and partdef views (repstate + partstate fields), related via repid. So I'd first verify this information is consistent across all you servers' syscdr databases. Should we be looking at some sort of inconsistency between servers, an affected replicate probably had to be deleted and redefined as the quickest way to resolution. Assuming consistency, you probably have got an 'Active' replicate with only some of its participants having been activated. Keep in mind that, when expanding an existing replicate by new participants (cdr change replicate --add), those new participants will be and remain inactive and require to be activated in a separate step. Should this be your situation, the required next step would be: cdr start replicate <repl_name> <server_list> with <server_list> being the blanc separated list of ER server names where the replicate appears inactive. Let us know if this helped! BR, Andreas ------------------------------ Andreas Legner ------------------------------

Thanks for the reply. This replicate was deleted and recreated like all the others but still can't change the state. Below the output for cdr list replicate on 2 servers DEFINED REPLICATES ATTRIBUTES ------------------------------ REPLICATE: A_per_property_A1 STATE: Inactive ON:grp_08_headq CONFLICT: Timestamp FREQUENCY: immediate QUEUE SIZE: 0 PARTICIPANT: warms:dwafdba.per_property OPTIONS: transaction,ris,ats,fullrow REPLID: 530997 / 0x81a35 REPLMODE: PRIMARY ON:grp_08_headq APPLY-AS: INFORMIX ON:grp_08_headq This is the one that does not change to active DEFINED REPLICATES ATTRIBUTES ------------------------------ REPLICATE: A_per_property_A1 STATE: Inactive ON:grp_26_ecape CONFLICT: Timestamp FREQUENCY: immediate QUEUE SIZE: 0 PARTICIPANT: warms:dwafdba.per_property OPTIONS: transaction,ris,ats,fullrow REPLID: 530997 / 0x81a35 REPLMODE: PRIMARY ON:grp_26_ecape APPLY-AS: INFORMIX ON:grp_26_ecape ------------------------------ Jaco Loots ------------------------------

So what's this going to return? for s in grp_08_headq grp_26_ecape; do echo "From $s:" dbaccess syscdr@$s <<! select repstate from repdef where repid = 530997; select servid, partnum, partstate from partdef where repid = 530997;! done ------------------------------ Andreas Legner ------------------------------

output for grp_08_headq Database selected. repstate 2 1 row(s) retrieved. servid partnum partstate 8 6293146 2 15 0 2 20 0 2 21 0 2 22 0 2 23 0 2 24 0 2 25 0 2 26 0 2 9 row(s) retrieved. Database closed. output for grp_26_ecape Database selected. repstate 2 1 row(s) retrieved. servid partnum partstate 8 0 2 15 0 2 20 0 2 21 0 2 22 0 2 23 0 2 24 0 2 25 0 2 26 4196265 1 9 row(s) retrieved. Database closed. ------------------------------ Jaco Loots ------------------------------

So neither replicate nor participants are in 'active' state, and what "cdr list repl" was hiding here, unfortunately, was that participant state '1' on grp_26_ecape which likely is the reason you can't activate this replicate. For those state numbers' meaning: select * from sysmaster:flags_text where tabname = 'cdrstate'; Participant state 1: "Definition failed" So something's not right with the grp_26_ecape participant of this replicate, and apparently something that didn't get detected at initial schema verification before replicate definition even is allowed to proceed. What I'd try: drop the replicate newly define it, for testing only, on grp_26_ecape, with only the grp_26_ecape participant watch out for errors on command line + in online.log on that server ------------------------------ Andreas Legner ------------------------------