Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Reply
Tuned Listener
Posts: 8
Registered: ‎04-24-2009

Re: File applied and resent because it was created before last database?

[ Edited ]

Paul,

 

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 Smiley Happy

 

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?

Message Edited by JeffW8 on 07-17-2009 10:32 AM
Bronze Super Contributor
Posts: 265
Registered: ‎04-14-2009

Re: File applied and resent because it was created before last database?

Paul, I received the HF on Friday and the documentation states this is an issue when the ONLY rule is Remote user wins (as below).

 

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?

 

 

 

 

Regards

 

Craig Frayne

Tuned Listener
Posts: 8
Registered: ‎04-24-2009

Re: File applied and resent because it was created before last database?

Craig,

 

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.

 

Thanks,

Jeff

Employee
Posts: 79
Registered: ‎06-25-2009

Re: File applied and resent because it was created before last database?

Craig,

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.

 

Thanks

 

Paul Zeimet

Development Manager

Sage SalesLogix

Paul Zeimet
Development Manager
Infor CRM
Bronze Super Contributor
Posts: 265
Registered: ‎04-14-2009

Re: File applied and resent because it was created before last database?

Jeff,

 

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.

 

Regards

Craig Frayne

Highlighted
Employee
Posts: 79
Registered: ‎06-25-2009

Re: File applied and resent because it was created before last database?

Craig,

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?

 

Thanks

 

Paul Zeimet

Development Manager

Sage SalesLogix

Paul Zeimet
Development Manager
Infor CRM
Bronze Super Contributor
Posts: 265
Registered: ‎04-14-2009

Re: File applied and resent because it was created before last database?

Paul,

 

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.

 

Regards

 

Craig Frayne

Bronze Super Contributor
Posts: 265
Registered: ‎04-14-2009

Re: File applied and resent because it was created before last database?

Paul,

 

Has there been any developments on this?

 

Regards

 

Craig Frayne

Tuned Listener
Posts: 8
Registered: ‎04-24-2009

Re: File applied and resent because it was created before last database?

[ Edited ]

Paul,

 

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.

 

Thanks!

Jeff

Message Edited by JeffW8 on 07-23-2009 08:14 AM
Tuned Listener
Posts: 8
Registered: ‎04-24-2009

Re: File applied and resent because it was created before last database?

Also, for anyone interested, my company has a different arrangement than that which was listed as the cause for the "List Index Out of Bounds" error.  Our conflict resoluction is set to "Most recent change wins", and if a change is made to a record on a remote office, then on the host office, and then the change from the remote office syncs in, we'll see the bad transaction and failed transaction produced as well.  My guess is that anything that could possibly trigger any type of conflict resolution will cause this issue.