Yeah, it doesn't sound like it's a time zone problem. As long at the timestamps in the databases are all GMT then it shouldn't be a bit deal.
There could be other things going on though, like the last updated stamp for a certain record on the target server could be more recent than the one on the source server (if seed/initial data was loaded on the source and then on the target, even if the source was updated before the target was loaded) then it would not write the record. Of course, if that happens it will tell you that it did that and you'll at least see it in the summary numbers that come back from the remote call.
It sounds like you have things far enough along that the only way to progress is with elbow grease. In other words pick a couple of records that you think should be transfered over but that are not getting copied, and then look at the data (on both source and target if applicable) and read through the code to see exactly what it would do with that data.
-David On Dec 7, 2007, at 10:27 AM, Vince M. Clark wrote:
I don't know for sure that we are dealing with a timezone issue. That is just one theory as we try to iron out some problems with entity sync. The fact that the same records always seem to be problematic gives us a pattern to pursue. I'll update the thread as we research the problem.----- Original Message ----- From: "Adrian Crum" <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, December 7, 2007 10:33:19 AM (GMT-0700) America/Denver Subject: Re: Strange behavior with Entity SyncI don't know if the recent time zone work would have any affect on this. It's a possibility.I'm not familiar with POS and entity sync, so I'll describe the changes I made and maybe others whoare more familiar with Vince's setup can figure it out. The basic concept is:1. Date/time String in UI (user's time zone) gets converted to TimeStamp (which is referenced toGMT), then it is stored.2. TimeStamp in storage (GMT) gets converted to date/time String for UI (user's time zone).3. Only the screen widget and Freemarker template code was changed.You shouldn't have to set all of your terminals to the same time zone as the server. If the problemis in OFBiz, we should fix it. -Adrian Vince M. Clark wrote:Yes. I pulled it from trunk about a week ago. ----- Original Message ----- From: "Jacopo Cappellato" <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, December 7, 2007 8:36:18 AM (GMT-0700) America/Denver Subject: Re: Strange behavior with Entity Sync Hi Vince, are you running a recent OFBiz revision? I guess that Scott asked you about the timezones because we haverecently refactored the way datetimes are treated in OFBiz: Adrian Crum worked on this, and he could better explain, but the idea is that when a date field is edited it is converted from the user session locale to thesystem locale.I think that Scott could be right... Adrian, do you think that your workcould have caused some side effects on the entity synch stuff? Jacopo Vince M. Clark wrote:It could be a timezone issue. We will test a bit more and try to nail down a pattern. We can isolate the problem to the same set of records that always get pulled incomplete.The server is set to GMT and all the POS terminals are mountain. When first setting up sync I had some difficulty getting the PULL to start running and suspected it was due to the timezone being in the future on the server. But we got past that.Given that we will have terminals in all US timezones it is not really a good option to set them all to the same time as the server.----- Original Message ----- From: "Scott Gray" <[EMAIL PROTECTED]> To: [email protected]Sent: Thursday, December 6, 2007 11:32:11 PM (GMT-0700) America/ DenverSubject: Re: Strange behavior with Entity SyncJust a stab in the dark but do these issues arise if the server and terminalare in the same timezone? Regards Scott On 07/12/2007, Vince M. Clark <[EMAIL PROTECTED]> wrote:BJ - your question is not ignorant, but I have no idea how to answer. We'll have to depend on others in the community much smarter than us.Entity Sync is a feature available in the system. We are using it and I can only assume that it works if configured properly. I have figured out the basics of push and pull synchronization. That is about as much intelligenceas I can claim.I can get into the details of what I loaded and where if necessary, suchas EnityGroup, EnittySync, RecurrenceRule, etc. ----- Original Message ----- From: "BJ Freeman" <[EMAIL PROTECTED]> To: [email protected]Sent: Thursday, December 6, 2007 4:35:09 PM (GMT-0700) America/ DenverSubject: Re: Strange behavior with Entity Sync ignorant question does not entity sync mess up the accounting.how are the ecas that are suppose to fire based on certain services,that do CRUD of the entity suppose to fire? am I missing some documentation on how this works? Vince M. Clark sent the following on 12/6/2007 1:58 PM:We are using entity sync to keep POS terminals and a central serversynchronized. We are going direct from POS to MCS, no Per Store Server involved. We have a pull sync (MCS to POS) and a push sync (POS to MCS.)Some data such as inventory is going both ways.A few issues: 1) Records deleted on MCS are not deleted on POS.2) Pull sync is not getting complete records in some cases. Two entitieswe see this consistenly is on Facility and InventoryItem. We get partial records sometimes. Note that this only seems to occur on the initial pull when we are first populating a new POS terminal from the central server. Once we identify a record, such as a facility, that didn't come down completely we can update the timestamp on the server and the next pull getsthe complete record.3) Related to item 2. If a push occurs from the POS terminal BEFORE weget the initial data correct, it overwrites the data on MCS. For example, if a facility record was pulled down and the store id is missing then when the terminal push occurs it trashes the facility record on the server. Strangething is we aren't pushing facility data, only pulling.Note that the server time is different than the terminals (differenttimezones.)Vince Clark Global Era The Freedom of Open Source [EMAIL PROTECTED] (303) 493-6723
smime.p7s
Description: S/MIME cryptographic signature
