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
