It has been a while since I used entity sync but I do remember that we definitely had issues with systems in different time zones where the system clocks were set to the local time. We solved it by setting all clocks to the same value and time zone, like GMT/UDT.
----- Original Message ----- From: "David E Jones" <david.jo...@hotwaxmedia.com> To: user@ofbiz.apache.org Sent: Saturday, January 10, 2009 11:54:38 PM (GMT-0700) America/Denver Subject: Re: Entity Sync Overwriting Data with Nothing Sounds like another fun issue... source repos messed up are a pain! Anyway, my guess is that what you described really IS an issue and I've changed some things in SVN rev 733423 that are more correct/ accurate in general and should fix this issue. -David On Jan 8, 2009, at 11:40 PM, Sam Hamilton wrote: > It seems that our local SVN server is corrupted and making a total > mess of OFBiz so please ignore this thread. > If we still get the same problem later with a proper copy I will > repost - thanks David! > > Sam > > > On 09/01/2009 08:46, "David Jones" <david.jo...@hotwaxmedia.com> > wrote: > > > > You have the same records being sync'ed in two directions? Hmmm... I > hope this is the only issue you run into. > > Here's my guess about why this is happening: > > 1. during the first data move the record is not in place when it is > referred to, so a dummy empty record is created > 2. the dummy empty record has the current data/time stamped on it > 3. in the second data move, opposite direction, that record is > included as a new record with the timestamp when it was inserted which > will be later than the timestamp of the original record, so when it > goes in the other direction it will be considered the newer record and > will therefore be used to overwrite the original record > > I'll look in the code and see if this can be fixed in step #2 by using > the timestamp of the referring record as the timestamp on the new/ > dummy record. That should work, and if it doesn't then we'll just use > that time minus something to make sure it is in the past. That > shouldn't be necessary since this is happening because the record in > question has a later timestamp so shows up later in the sorted > records. > > -David > > > On Jan 8, 2009, at 2:53 AM, Sam Hamilton wrote: > >> We are currently deploying OFBiz in multiple locations (USA, Hong >> Kong and China) but when the remote servers try and sync via push >> with the master server it looses the shipment receipt info and only >> the primary key exist, all other fields are empty. Then when the >> pull is invoked from the master to the remote servers empty data is >> overwritten into the fields where data was. >> >> Here are the logs: >> The log info: >> 2009-01-07 11:08:47,637 (RMI TCP Connection(7)-192.168.3.4) >> [ GenericDAO.java:970:INFO ] Count select sql: SELECT >> COUNT(1) FROM public.SHIPMENT_RECEIPT WHERE (RECEIPT_ID = ?) >> 2009-01-07 11:08:47,639 (RMI TCP Connection(7)-192.168.3.4) >> [ GenericValue.java:464:INFO ] Set [receiptId] to - SH26111 >> 2009-01-07 11:08:47,653 (RMI TCP Connection(7)-192.168.3.4) >> [ GenericValue.java:470:INFO ] Creating place holder value : >> [GenericEntity:ShipmentReceipt][receiptId,SH26111(java.lang.String)] >> >> Anyone any ideas how to stop this happening? >> >> Thanks >> Sam > > > > Sam Hamilton > CTO > Virtual Village > > Tel: +86 (21) 6271 3051 > Fax: +86 (21) 6271 3021 > Mobile: +86 (135) 2451 4480 > E-mail: sam.hamil...@virtualvillage.com
