Why do you say the 28th is the last working one? What is in your "*Items to NOT synchronize*" for the central and child servers? That should be the only way items are not written to the sync_server_record table.
Have you restarted the server? Ben On Tue, Apr 3, 2012 at 1:07 AM, Erick Mugoma <[email protected]>wrote: > Hi Dave, > I believe my configuration is ok. Am able to see all the child servers. > What I don't understand is why the parent server is no Longer marking the > records for sync and inserting them in the sync_server_record table?. > By the way everything was working fine till 28-03-12. I can't tell what > happened that stalled the sync process on the parent. > How do we ensure that the records are being inserted in the > sync_server_record table. I suspect that this is where we are having > trouble? > > Thanks > > Erick > > > On Mon, Apr 2, 2012 at 11:16 PM, Dave Thomas <[email protected]> wrote: > >> Hi. If you're not seeing any new records in sync_server_record on the >> parent, you're in trouble. This is the table that is used to keep track of >> what records have propagated to what child servers. Without rows being >> inserted into this table, no data will ever propagate to the children. In >> your sync overview page on the parent, can you actually see the child >> servers, and are they configured correctly? >> >> Did you change the server uuids at all, either on the children or on the >> parent? >> >> On the parent, the state field in the sync_record table isn't important. >> Its the state field in the sync_server_record that governs propagation. >> >> d >> >> >> On Mon, Apr 2, 2012 at 8:05 AM, Erick Mugoma <[email protected]>wrote: >> >>> Hi Ben and Mark >>> Am just wondering what may or may not be happening with the >>> sync_server_record and sync_record tables on the central/parent server. >>> Plse help me understand something, I expect that every time a new record >>> is created on the parent, the record details are logged to the above tables >>> and you can even use these tables to track if the record was committed, >>> sent, new or failed. Why is it that when I do a query to check if there >>> any records in the sync_server_record table I can't see any record for >>> example I should be able to see today's records (02-04-12) since the clean >>> -up was last done on 31 march 2012. Any I deas on what is not Happenning? >>> >>> On the parent sync_record table, the state field is not being updated. >>> The state column value is 'NEW' for all the records. I expect that the >>> state should change once the record is committed to all the children. Any >>> reason why this is not so? >>> >>> When I look at the same table on the child servers, the state column >>> value is 'COMMITTED' >>> Looking at the History Changes on the UI What I see are old changes like >>> last updated is 28-03-2012. That is last week wed when we have new records >>> being entered even today (02-04-12) and should be able to see them under >>> history changes. Any Explanation why I can't see the newest/latest updates. >>> >>> Thanks >>> >>> Erick >>> >> >> > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
