07-08-2009 01:44 PM
We are currently seeing the following message (paraphrased) during sync cycles on our Synchronization server for a bunch of different files:
"The file 5UWE-A403Q65.4UDO will be applied and resent to the remote because it was created before the last database." We have several of these messages an hour, and the file names are all different. I checked the key base and those are the same, so it appears the message is actually false (maybe I'm reading it wrong?)
Also, we have been seeing a ton of these error messages in our failed transaction TEFs:
"ERROR: ParamSQLUpd - Error applying ParamSQL transaction A26EFYS : List index out of bounds (0). SQL: SELECT MODIFYDATE,CONTACTROLE FROM C_CONTACT WHERE CONTACTID = 'C6UJ9A000P95'". There are several tables we are getting this message for, and it appears the majority of the failed transactions actually originated from the database that they subsequently failed on. Therefore, I think the two issues might be related. And just to be specific, everything about the error is the same, except for the actual SQL - table, columns and conditions.
So far I have been able to identify the TEFs sent from the sync server to the remote office and find the specific errors that are subsequently produced, but I can't figure out why they sync server is sending them in the first place, and I'm about to try and test the theory about the transactions originating at the remote database first. The only problem with testing is that we still can't reproduce on command, even though it is occassionally happening in our test environment.
Here are some statistics about our installation:
SalesLogix Version 7.5.1 (Upgraded from 6.2.6 a few months ago)
SQL Server 2005
App Server, Sync Server, and DB Server all separate servers
Around 80 remote users and 4 remote offices
We would appreciate ANY thoughts on this - we're pursuing all available channels to diagnose this issue. I may be posting this question on the other two public boards (SLXDeveloper.com and ITToolbox) for a wider audience, but I wanted to try this board first, since it is the Sage board.
Solved! Go to Solution.
07-08-2009 02:10 PM
Jeff, you cut the database for this user whilst SyncServer was running. It's a known fact that if the SyncServer runs whilst the DB is being cut then the overlap creates an issue. You must, whilst cutting remotes, stop the sync server as you cut remotes. A little inconvenient - but it's the reason you are getting these messages. Just delete them otherwise it'lll keep looping. Alternatively, re-cut (with s/server stopped).
This list index out of bounds is fixed in HF25 (released very soon).
PS Don't forget the kudos !
07-09-2009 10:35 AM
I'm extremely grateful that you replied to my post and at least voiced some thoughts. Thank you so much, and if I can figure out how to do the Kudos, I will. I clicked on the Kudos star (and my cursor even transformed into the pointing hand), but it didn't work - maybe a problem with the FireFox 3.0 browser?
I guess, given the nature of some of the new posters and their complete inability to do anything in SalesLogix, I can understand the quick assumption that I'd cut a remote office database while sync server is running. Didn't happen. We had cut every remote database, including all four remote office databases, immediately following our upgrade of SalesLogix from 6.2.6 to 7.5.1., and I can assure you - sync server was definitely not running when we cut those databases back in april. Also, wouldn't it be unlikely that we'd still be seeing a constant flow of those messages months after the database was cut? Either way, I'm just curious if there's a field somewhere in the database that we need to look at that has something to do with these mysterious decisions that Sync Server makes. I'll add a task to run profiler while sync server is running, and maybe I'll catch a SQL statement that checks the database.
As for the list index out of bounds error, if it addresses my issue, that's pretty exciting! Means we might have a fix for our worrisome problem. However, I just heard that Sage dealt with this error with another company, and the issue they communicated to us as a possibility turned out not to be our issue. I wonder if this error is just so generic that it covers a multitude of issues? Is there any documentation available to non-BPs for HF25? I'd love to see if I can stop attempting to resolve this error.
07-09-2009 10:52 AM
Ah right, I see (!). In order to track this down you will need to examine the table SYNCFILETRACKING and in particular the status column. In here you can see what's being attempted to be applied. You can then verify this against the files in infiles (this will be on the sync server as this is where the problem is being shown [correct?). Your best tool for this is trnViewer.exe as this enables you to see inside the TEF's (slxprofiler shows you what happens at the SQL/Provider level). You are running 7.5.1 so there are no HF's yet for Sync. It may just be a case of bad/old files in the outfiles of the remote - which come into the server, are re-wrapped and sent back to remote (which is what the message indicates) so check the dates of the files on the remotes.
Another thing to do is to capture copies of the state of infiles/outfiles prior to S/Server running - that way, you can go back and identify the bad tefs whcih may lead you down the right route.
Hope this helps.
07-10-2009 10:05 AM
The first issue: "The file 5UWE-A403Q65.4UDO will be applied and resent to the remote because it was created before the last database."
Would likely be happenning for a particular site. In the case above "4UDO".
This happens when the ApplyIndex in table SyncSequencing get out of sync with the remote.
Look at the ApplyIndex for SourceSite "4UDO" in the case above and compare this with this portion (5UWE-A403Q65.4UDO ) of the files coming from this remote.
The smallest value coming from this remote should match the value in SyncSequencing "ApplyIndex" for SourceSite "4UDO"
Your second issue: "ERROR: ParamSQLUpd - Error applying ParamSQL transaction A26EFYS : List index out of bounds (0). SQL: SELECT MODIFYDATE,CONTACTROLE FROM C_CONTACT WHERE CONTACTID = 'C6UJ9A000P95'".
This is definately fixed by HF25 for 7.5.1. This should be available for general download from support online either today or tomorrow I believe.
The issue here was a defect with conflict resolution that was causing transactions from remotes that failed conflict resolution to send back a SELECT statement to the remote instead of the correct UPDATE statement.
Hope this helps!
07-10-2009 10:09 AM
Correction to last post: The smallest value coming from this remote should Greater then the value in SyncSequencing "ApplyIndex" for SourceSite "4UDO"
07-13-2009 02:56 AM
From the previous post• Re: SLX 7.5.1 sync errors - list index out of bound (0)
Which is the same issue, I am also seeing the file will be resent as it was created before the last database, having done some testing, this is what I am seeing.
Firstly this is on a test Eval DB with two remotes cut, firstly I see two entries in each of the remotes syncsequencing tables, one is the correct one where the sourcesite is the host and targetsite is the remote.
The second entry has the sourcesite containing the host and remote for example NW6W-1U2V (I have seen this before but have never had a real explanation of how or why this occurs).
In both instances of the remotes, they are using the row with host and remote sitecodes, i.e. NW6W-1U2V as the entry for the sendindex however in the host syncsequencing the applyindex is not incrementing and appears to me that is was using the first rows entry at some stage and has somehow changed to use the second rows entry and is now obviously wrong.
SOURCESITE TARGETSITE SENDINDEX LASTSEND APPLYINDEX LASTAPPLY MODIFYDATE MODIFYUSER CREATEDATE CREATEUSER
1U2V NW6W A20002V 2009-07-13 09:26:39.000 A20003P 2009-07-13 09:00:36.000 2009-07-13 09:26:39.000 ADMIN 2009-06-22 14:00:27.000 ADMIN
SOURCESITE TARGETSITE SENDINDEX LASTSEND APPLYINDEX LASTAPPLY MODIFYDATE MODIFYUSER CREATEDATE CREATEUSER
NW6W 1U2V A20003R 2009-07-13 09:25:10.000 A20002T 2009-07-13 09:23:09.000 2009-07-13 09:23:08.000 ADMIN NULL NULL
NW6W-1U2V 1U2V A20002V 2009-07-13 09:25:12.000 NULL NULL 2009-07-13 09:25:11.000 ADMIN 2009-06-23 09:50:18.000 ADMIN
The remote is sending out files from the latter entry sendindex, however as you can see above in the host syncsequencing the applyindex is on A20003P
Something is very wrong here and whether this is related to the failed trans issue I do not know, however I do not recall seeing this msg in the syncserver prior to 7.5.1 although as far as I am aware there have not been any changes in the sync process between 7.5.0 and 7.5.1.
But something is not at all right and think it far to much of a coincidence that other people are also seeing this msg, I suspect if checked they will also have the two entries in the remotes sitecodes.
Can this be looked into and or can you offer an explanation on the following.
1) When this msg was introduced and what functionality has changed, (seems there is now the ability to resend files to older remotes).
2) How and why is a second entry created in the syncsequencing table containing the host and remotes sitecodes.
07-13-2009 11:58 AM
Mike, Paul, and Craig,
Thank you SO much for replying to my post. I apologize for starting up a separate additional post on the issue. I was all searched out on ITToolbox and SLXDeveloper.com, so I just jumped right in with my issue once I came to this forum. Craig, I'm glad you added a link to the other thread. Mike, I had been using TrnViewer.exe a lot - I was just mentioning that I used Profiler as an additional tool to see what was happening.
As of this post, HF25 still isn't posted. I understand there might be some circumstances for this, but what really makes me curious right now is knowing where the HF will need to be applied. Since it addresses conflict resolution, will we only need to install it on the sync server, or will we be required to install it on every remote installation (office and user)?
As a temporary solution until we can safely work HF25 into our production system, would it resolve this issue to temporarily turn off conflict resolution? I know it is definitely less than ideal, but we're starting to see this error as an even bigger pain. Currently it is set to "made the most recent change, and I'm talking about setting it to "<Not Used>". I wonder if because we have all these errors due to conflict resolution, if our data might be cleaner without it being active, at least until we can get the HF installed.
As for the other message that Craig and I have started discussing, Paul - do you know if this is related to the conflict resolution error? If it isn't, is the solution to manually update the records in SyncSequencing, and if so, once we correct the problem will it stay on track, or should we monitor it? Sorry about all the questions - and thank you again for taking the time to read and reply to our posts.
07-13-2009 12:17 PM
I am checking on the status of HF 25 to see when it will be posted.
This HF only affects SyncServer and therefor will not require installs on any remote machines.
I don't believe turning off conflict resolution will be helpful. If HF 25 is not posted today, you can certainly request it from Support by asking for the "Customer Validation" version. I do know that it has passed customer validation.
The other issue I still need to research today based on Craig's post. I will try to get back to both of you today on that.
07-14-2009 11:59 AM
When a remote database is cut, SyncSequencing table is empty to start with.
SyncClient populates this table when it creates the first TEF to send.
It first creates this record: NW6W 1U2V A200000 2009-07-13 09:25:10.000 A200000 2009-07-13 09:23:09.000 2009-07-13 09:23:08.000 ADMIN
Notice SendIndex and ApplyIndex are intialized to 0. This is expected because the KeyBase is incremented. A200000
The very next file that is sent, SyncClient creates the second entry: NW6W-1U2V using the current values from the previous record. This new entry is used for all subsequent sends, while the first entry is still used to track applies. This was introduced years ago and I don't quite remember the reason.
This should not be an issue at this point because the host should have sendindex with keybase of A1 until the first sync cycle is executed.
When the SyncServer receives the first files from the remote after the cut, it will update its applyIndex to match since the keybase value on the incoming files is greater.
I'm not sure how your remote got out of sync with the host, but you should be able to set the ApplyIndex on the host to be one less than the lowest value coming in from your remote.