3.2 No Send/Receive

[birdld-p40]

I would be utterly fascinated to understand why renaming the log file would solve this problem. Buy time, if MLS is not handling the file properly, or if it has grown too large, yes. But, solve the problem?

Although, if it works for others, try it. I have seen stranger things.

The mlslog.txt file seems to be the result of another error. MLS hangs somewhere trying to load the patch. The result is a very large mlslog.txt file which hinders MLS from communicating again. Until this file is deleted or renamed you will not be able to transmit. Programmers are looking into it, but are still unsure of the actual cause.

[techgy]

The mlslog.txt file seems to be the result of another error. MLS hangs somewhere trying to load the patch. The result is a very large mlslog.txt file which hinders MLS from communicating again. Until this file is deleted or renamed you will not be able to transmit. Programmers are looking into it, but are still unsure of the actual cause.

Would it be advisable to do a complete re-install of 3.2?

[dwterry-p40]

The event at 2pm is the key. The unit is still running 3.1.5 at that moment, and due to a bug in 3.1.5 it is filling up the mlslog.txt file. When you later attempt to do another transmission, the log file is so large that it cannot be effectively transmitted and so the transmission fails.

Deleting or renaming the mlslog.txt file will solve the problem. With potentially limited space on hard drives, deleting the file may be the better option.

MLS 3.2.0 (the version being downloaded to the units), is immune to the problem. Unfortunately, the problem is in MLS 3.1.5 and appears to be happening as people continue to use MLS after receiving MLS 3.2 but before completing the upgrade process.

Best suggestion for anyone who hasn't yet upgraded to MLS 3.2: Reboot immediately after receiving the update. Don't wait, don't do other MLS work. Just take care of the reboot and things should be fine after that.

One complicating factor: MLS 3.1.x had reliability issues with showing the reboot dialog. So you may not realize you have received MLS 3.2 unless you were watching the status bar.

We're having the same problem... Here's the history of what happened:

Sunday:

• 10:30 am - Membership clerk transmits membership updates, MLS 3.2 starts downloading
• 10:55 am - download finishes
• 11:00 am - 12 noon - various people use the computer for reports and other duties, the computer is never rebooted (I'm guessing that someone saw the message to reboot the computer to apply the update, but they must have forgotten to reboot)
• 12:20 pm - we start doing a donation batch
• 1:20 pm - we transmit the donation batch, finance transmission report prints
• 1:30 pm - I start entering in expenses to write some checks
• 2:00 pm - when I click the "Print Checks" button, javaw.exe pegs processor 100% for 3 + minutes, I do a "force quit" on the .exe file via task manager and reboot the machine
• 2:05 pm - I start MLS after a reboot and it finishes applying the update
• 2:06 pm - 3:00 pm - I'm able to print the checks (23 of them), but I can't successfully transmit... when I click send/receive, it dials the number (we are on dial-up) and then it never gives me a progress bar or anything letting me know it is transmitting...
• 3:00 pm - I lock the office and put a note on the computer: "Please let the computer finish transmitting" and I go home.
• 7:00 pm - I return to the church to see if it finished transmitting... the modem had disconnected but the expenses were still "Not Sent" on the "View/Update Expenses" screen. I try transmitting again and it doesn't work (it dials, connects, and then sits).

Anyhow, I'm about to call CHQ to let them know about these 23 checks that we wrote yesterday. I'm sure enough of us will be manually calling in new expenses that they'll realize something isn't right.



Thanks~!

[mamadsen]

I have had one of my units try the fix as posted here and it worked. The mlslog.txt file should normally be relatively small. The one unit that renamed the file noted that the file size was over 500MB with over 5 million lines.

What we need to find out is if changing the name of this file fixes the bug or will we need to continue to rename this file until a permanent fix is downloaded in the next update?

[dwterry-p40]

It should be a one-time occurrence. MLS 3.2 is immune to the problem (fixes a loop that writes an exception to the log).

I have had one of my units try the fix as posted here and it worked. The mlslog.txt file should normally be relatively small. The one unit that renamed the file noted that the file size was over 500MB with over 5 million lines.

What we need to find out is if changing the name of this file fixes the bug or will we need to continue to rename this file until a permanent fix is downloaded in the next update?

[techgy]

I have had one of my units try the fix as posted here and it worked. The mlslog.txt file should normally be relatively small. The one unit that renamed the file noted that the file size was over 500MB with over 5 million lines.

What we need to find out is if changing the name of this file fixes the bug or will we need to continue to rename this file until a permanent fix is downloaded in the next update?

As noted below, v3.2 is immune to the problem.

....Deleting or renaming the mlslog.txt file will solve the problem. With potentially limited space on hard drives, deleting the file may be the better option.

MLS 3.2.0 (the version being downloaded to the units), is immune to the problem. Unfortunately, the problem is in MLS 3.1.5 and appears to be happening as people continue to use MLS after receiving MLS 3.2 but before completing the upgrade process.

[jpjones~ogr]

The solution presented here worked great. Finding the file took a moment, but my stress level dropped significantly once send/receive functioned.

Many thanks for quick and easy access to prompt and effective answers.

[techgy]

Deleting or renaming the mlslog.txt file will solve the problem. With potentially limited space on hard drives, deleting the file may be the better option.

MLS 3.2.0 (the version being downloaded to the units), is immune to the problem. Unfortunately, the problem is in MLS 3.1.5 and appears to be happening as people continue to use MLS after receiving MLS 3.2 but before completing the upgrade process.

Thanks for the suggestion. It worked perfectly.

[CWatsonJr]

Okay, I spoke with the MLS Help people at CHQ and here is what they said:

"Numerous people have been having this problem and what seems to have worked so far is the following:

Close MLS if it is open
Navigate to C:\program files\lds church\mls\
Find the mlslog.txt
Rename the file to mlslog1.txt or mlslogOLD.txt or something similar
Start MLS, Login, and try transmitting"


Since I'm not at the church building right now, I'm unable to test this. Does anyone want to try this? Has this worked for other people?

Thanks~!

This solution worked for us as well. Our log file is over 600Mb in size so if I am able to delete it, that would be nice. I have just renamed it for now.

Thank you very much for your input!!!

[PNMarkW2]

To the best of my knowledge we have not been having the Send/Receive issues here, but just for fun I checked out mlslog.txt file, it was only 80k.

We ARE having another issue when we do a Send/Receive though, each and every time a dialog pops up warning us we're connecting to the PRODUCTION database and requiring us to enter "yes" before it will proceed. We did not have this message priot to the update, any ideas on how to get rid of it?