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" <[email protected]> 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: [email protected]
