5/12/2025 4:35:57 PM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss SalesLogix synchronization and remote database management. View the code of conduct for posting guidelines.
|
|
|
|
Newly cut remotes generating huge outfiles
Posted: 25 Mar 08 6:39 AM
|
Two new remotes were cut last week – sync failed soon after. Site code (806U 1300 accounts); (DFPF 18592 accounts)
Now the sync cycle starts and runs up to sending new accounts to remotes:
U[3/22/2008 10:11:17 PM]Selecting accounts ...
U[3/22/2008 10:11:17 PM]Removing accounts ...
U[3/22/2008 10:11:17 PM]Sending new accounts to remotes...
M[3/22/2008 11:18:59 PM]A trapped exception occurred: Access violation at address 00797B0C in module 'syncserver.exe'. Write of address 00000000
Data seems to be getting exchanged between other users/remote office after sync fails.
Sequence:
Sync cycle starts and runs until ‘Sending new accounts to remotes’ – This runs for a while sending accounts to remotes – existing remotes seem to runs for over an hour.
The progress indicator gets stuck on 57 of 100 records for 806U and 99 of 100 accounts for DFPF- making huge outfiles - some over 400meg – I ran out of disk space, cleaned off 25g and I am starting to run out again.. I believe the newly cut remotes should be around 8 gigs each. One of the new remote user's files finish each cycle, sending 99 of 100 while the other one grinds away on 57 of 100 until it throws the Trapped Exception. - I can see the files for the remote users in the writecache folder continue to grow - even after the Trapped Exception error message, 806U was taking way longer in writecache, but DFPF is taking longer now. Eventually they process and clear the writecache folder leaving huge outfiles.
If I try to open an outfile for one of the users with the transaction viewer I get the following error (both have a keybase of A1 in the admin profile and outfiles):
"Error reading file "D:\Sync Logs\Outfiles|Zip-WZX1-A10007B.DFPF" Version Error. Transaction file is a future version.
Has anyone seem similar issues?
|
|
|
|
Re: Newly cut remotes generating huge outfiles
Posted: 25 Mar 08 8:31 PM
|
If you create the new remotes with your subscription rules correctly in place, you should not have the overhead of all the accounts gradually syncing out to them afterwards ... they should already be in the newly created db.
Not seen the behaviour that you are describing, but if you can head it off, maybe the problem goes away.
I'm sure you know about attachments and how they start syncing out to new remotes, unless you take evasive action up front ... but if not and it's causing a similar problem, post again and I'll describe how.
Phil |
|
|
|
Re: Newly cut remotes generating huge outfiles
Posted: 26 Mar 08 6:46 AM
|
I have asked tech support before why so many accounts need to sync directly after the cut, but they can never give me a good explaination. The subscription rules are pretty simple and being used. Attachments do seem to be what is building up in the outfiles, but the client wants the remote to have all the attachements for the accounts/contacts/opps they get.
I knocked the 'Number of threads to send new accounts' down to 1 from 6 yesterday - not sure why it was set at six. That has helped me finish a sync cycle. It almost seems like files were being reprocessed along the line, creating these huge outfiles. Sync was finishing gracefully for a short time until I ran out of disk space again..
Still struggling with disk space, but more is on the way.. I am now getting an error:A trapped exception occurred: CloseAndRenameStream 1 Access violation at address 0083E10B in module 'syncserver.exe'. Read of address 00000000
I think it might be because of disk space.. |
|
|
|
Re: Newly cut remotes generating huge outfiles
Posted: 27 Mar 08 2:35 PM
|
An 8gb (x2) database is generating upwards of 25gb+ some change of data before running out of space? That doesn't sound right. TEFs add overhead but not *that* much.
When I haven't created a user in a while I'll sometimes forget to set their sync to all accounts considering we don't have sync rules. I can notice the difference because their database will be 50mb versus a usual ~250. I just recut before sending to them and I don't have to worry about it, but since we aren't using subscription rules at all it bypasses the problem entirely. It sounds like what Phil reports the behavior to be the same regardless of whether or not subscription rules are used.
There is the "send new attachment" option that can easily generate a lot of TEFs and combined with account metadata that could easily surpass 25gb. Those TEFs are usually in the format "ZIP-FILE*.SITECODE which is pretty easy to notice when looking in the directory. It wouldn't be a bad idea to browse the TEFs that do get created to see what it's doing. If you've got 8gb of data as the end result it makes more sense to just send it directly than tie up your sync processes.
There is one thing that jumped out at me when I read your initial post: "D:\Sync Logs\Outfiles|Zip-WZX1-A10007B.DFPF". Look at the character before Zip-. Isn't it supposed to be a \? | is the shift of the slash key so is it possible that was entered wrong somewhere? Then again you said TEF viewer which I believe does use that character for some strange reason.
Which version btw? Did you recently upgrade to say SP2? Wondering if that error just means the TEF viewer can't read the newer TEFs. That might indicate something was wrong in the upgrade process though highly unlikely. |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|