Correct. After updating timestamps the records pulled correctly. Of course you need to make sure you aren't doing a PUSH in the other direction that overwrites the records that did not pull correctly.
Changing the timestamps is just a tool to help you isolate your problem, not a solution. The timestamps I changed were the ones on the records that did not pull correctly, NOT the runtime entities or job. It has been quite a while since I did this, but here are the steps I think you should take: 1) Initiate your PULL with a recurrence of about 5 minutes (do not setup any PUSH processes yet). 2) Locate a record known to not PULL correctly and verify that it did not pull this time. 3) Update the timestamp on the MCS for that record. Have the xml ready to load thru web tools before starting the PULL process. The key here is to just make sure the date and time is set to something later than when the job ran. 4) Let the PULL run again and check the record on the POS client to see if it updated properly this time. If this test doesn't work, check your time settings on both machines. As I stated previously, I suggest setting both servers to the same time and time zone, Do this at least during testing to eliminate possible variables. I found it easier while troubleshooting this problem to start clean with every test. That means dropping and recreating the database on the POS client a lot. ----- Original Message ----- From: "Pradeep Kumar" <pradeep.ku...@palindromesoftware.com> To: user@ofbiz.apache.org Sent: Saturday, January 24, 2009 4:16:01 AM (GMT-0700) America/Denver Subject: Re: Improper PULL synchronization from MCS Hi Vince, As per you, you did the initial PULL, then updated the timestamps on the records and they got pulled properly the next time. Can you pls put some help here that how can we update the timestamps on the records we need for PULL? Is it something different than what happened always before the PULL call becuause before that it updates the next runtime and entitties too? Need help. regards, Pradeep On Sat, Jan 24, 2009 at 5:19 AM, Vince M. Clark <vcl...@globalera.com>wrote: > Agreed, they could still use the web POS interface but run local instances. > You would still have sync to deal with but OfBiz could focus on a single POS > UI rather than maintaining two. > > ----- Original Message ----- > From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> > To: user@ofbiz.apache.org > Sent: Friday, January 23, 2009 4:47:28 PM (GMT-0700) America/Denver > Subject: Re: Improper PULL synchronization from MCS > > From: "David E Jones" <david.jo...@hotwaxmedia.com> > > > > On Jan 23, 2009, at 3:06 PM, Jacques Le Roux wrote: > > > >> Yes, I agree. I think I will definitively put some effort on this > >> side (WebPos I mean). This for this reason and the others being that > >> XUI is no longer supported and we have issues with it. > >> So it's not yet sure but I'm more an more thinking that the POS > >> component will be legacy on day ... > > > > I doubt the current POS will ever be "legacy" or be abandoned, > > although it depends on how many choose to use it. > > > > Typically organizations want easier deployment, so a web-based > > application is great for them. > > > > In some cases things are very "mission critical", like getting money > > from customers in physical retail locations. In those cases redundancy > > and minimizing single points of failure is important. If the internet > > goes down or even the network in the store, they want each cash > > register to be able to run independently. For all but the smallest > > retailers that's a mandatory requirement. > > They could use the same mechanims with WebPos isn'it (a local DB > synchronized) ? > > Jacques > > > -David > > > -- With regards, S K Pradeep kumar
