07-17-2009 10:29 AM - edited 07-17-2009 10:32 AM
Thanks for your assistance - I'm sorry I haven't replied yet until now. I'm currently working through the two issues in our environment. We're testing the fixes first (HF 25 and resolving differences in SyncSequencing), and I'll post the results - I'm looking forward to marking your post as the solution
Quick question - we still don't see the HF on the support website. My manager's worried that even if we can get the fix from support, there may be some reason why it isn't posted yet, such as final approval. Are there any worries about the HF?
07-20-2009 04:58 AM
Conflict resolution fails when only rule is Remote user wins and more than one remote user makes updates.
We have the default rules setup with all three populated, I did query this with UK support but have not had a response, I wnet ahead and installed the HF and have not thus far had any of the same failed trans that we were receiving.
However and very worrying we have had three failed trans where the update statements are not correct, these have all been on the opportunity table and containing an update to an opportunity, the statements however do not contain a field to update, example below.
ERROR: ParamSQLUpd - Error applying ParamSQL transaction A401Q2X : Failed to parse SQL. SQL: UPDATE OPPORTUNITY SET WHERE OPPORTUNITYID = 'O7NPW0000006' (Blob size : 278) Table Name = OPPORTUNITYParamCount:0 SQL = UPDATE OPPORTUNITY SET WHERE OPPORTUNITYID = 'O7NPW0000006'
As you can see there is no field to update in the statement, whilst I need to investigate this to see what the users were updating, I have not seen this issue previously and am concerned the only change is the application of HF 25 and this could be the cause of this new issue.
Can you advise if this has been reported elsewhere?
07-20-2009 07:46 AM
Thanks for the update on HF25. In all the analysis that I've done, I've never seen a failed transaction like the one you've described for the Opportunity table. Just to be sure, I went back and checked a whole bunch of failed transactions for that table. Sounds like it may be a new issue. Does the frequency of the new failure match the frequency of failures that HF25 addresses, or does it happen considerably less often? It's great news that HF25 resolved the previous issue, and I'm hoping the benefit outweighs the negative.
07-20-2009 08:15 AM
I have not the issue you are reporting.
I have not seen any similar issues after installing HF25, but I will make sure to investigate this immediately!
I will let you know as soon as I have any further information about your issue.
07-20-2009 08:47 AM
It is difficult to say on the frequency aspect as it only appears to be related (thus far) to opportunities, the previous issue is deemed to be when two or more remote users update the same record in the same sync cycle we only have around 10 remote users so the frequency we were seeing the issue was not immense but is obvioulsy going to be compounded by the amount of remote users one has.
At present I am unsure what it is on the opps that is being updated to cause the issue, however as it appears that something shoud be being updated (not sure what) then this update is failing thus the remotes are not going to have the correct data.
At this stage I don't know if this new issue is related to HF25 or not but seems a little coincidental that it has only just started to happen, depending on how much of an issue the List index out of bounds (0). failed trans is affecting you I would be tempted to hold on for the moment with HF25, as at least the data is intact as it is sending out the updates to the remotes where it originated from and the data is already correct there.
If our new issue is caused by HF25 then I don't know if it is a twist on the original issue or not but suspect the data will now not be correct.
07-20-2009 11:27 AM
I've done some initial investigation into your issue.
It appears to be caused by one of two scenario's:
1) Transaction applied to server from remote has a conflict, but none of the individual fields in the transaction are in conflict. I don't believe this could actually happen, but it is a hole in the code to be fixed. What this would mean is that the entire transaction applied correctly at the host, but because sync thought there was a conflict it tried to send back a reverse transaction to the remote to either overwrite their changes (in the case of Host won) or reapply their changes (in the case Remote won). This should not cause any data loss.
2) Transaction applied to server from remote has a conflict, and all the individual fields in the transaction are in conflict. The reverse transaction, in the case would contain all the correct values to be sent back to the originating remote. However, the transaction sent to other remotes for this change would be modified to only include changes that successfully applied to the Host. Because all fields were in conflict and were rejected, there would be no changes to send to other remotes (the original host changes would already be sent to the remotes). This would cause the transaction you see with no update fields. This also would not cause data loss, but should be fixed.
I will get with QA today to try to get these scenario's reproduced and validated.
If I may ask, what are your conflict resolution rules?
07-21-2009 12:58 AM
Many thanks for looking into this and for the update, with regard to the conflict rules, we are using they are the default OOTB rules.
1. The user wins if he or she is a Remote client.
2. If after step one both users are equal, the user wins if he or she is the owner of the record.
3. If after step two both users are equal, the user wins if he or she made the most recent change
I have not as yet been able to clarify with any of the users (as they are all out and about) what changes they have made to the opps, it does however seem strange that thus far it only appears to be affecting the opportunity table as I have yet to see any failed trans affecting other tables.
Please let me know if you need anything further to assist.
07-23-2009 07:30 AM - edited 07-23-2009 08:14 AM
I can confirm that HF25 does take care of our List Index Out of Bounds (0) errors, but has also introduced the error that Craig has mentioned above. The only difference is that we have only seen the error on our C_UserInfo table so far. We only have the HF installed in our QA environment, and the transactions tested so far are canned, but we ran numerous transactions against numerous tables (including opportunity). I can also confirm that the result of the failed transaction did not cause data loss, as it appears the transaction shouldn't have been sent to that remote office anyway.
I also wanted to check up on the reason why HF 25 hasn't been posted on the general support site yet. Could it have anything to do with the newly introduced error that Craig had mentioned earlier, and if so, is there any chance that HF 25 will be modified to eliminate that new issue as well? Any information available would be helpful, even if you can only say that we should either wait to install HF 25 in our production environment, or to go ahead.
Lastly, since HF 25 did resolve our List Index Out of Bounds issue, I'm going to mark your post that announced HF 25 in this thread as the solution, but I really haven't had time to confirm the issue I listed in the subject of this thread yet. I hope to look into it a little further today or tomorrow. My only question on it is if there's a chance the issue can occur due to the timing of synchronization between the remote office and the sync server. Sometimes the remote office will get a few syncs in while the sync server is churning on a large number of transactions, and every once in a while the opposite is true. We only see the "File applied and resent" message every once in a while, so it appears that SyncSequencing may be going in and out of sync constantly.
07-23-2009 08:29 AM