Ward Meeting Time Incorrect

[preston.baxter]

I hadn't thought of that. When I called clerk support they said the websites update on Wednesdays, but when attempting to make MLS changes on Sunday, I had always only put a "future date" of Monday or Tuesday of the same week. Perhaps by the time the Wednesday update rolled around, the "future date" had become a "historical date" and is the reason it didn't update.

Assuming we change our meeting time mid-year, I'll experiment with setting same-week future dates, as well as setting the date further in the future.

[lajackson]

Ok. I have one unit that absolutely will not change. How far in advance does the effective date need to be?

I have set the new time to be effective two days after the Send/Receive. Two weeks later, there had been no change. I then tried one effective five days after the S/R. After another three weeks, there has been no change.

I set the new time for 10 days after the Send/Receive, and it has now been five days since the effective date and there has been no change.

Question #1: How far in advance do I need to set the effective date of the change?
Question #2: How long should I wait for the LUWS to be updated?

Question #3: What do you suggest I say to those who are actually looking at the site and showing up to the wrong meeting? We have a very transient pair of units in one city and there have now been two cases where members have dutifully checked the site, and come to the wrong sacrament meeting.

I solved that by putting a note at the site under the sacrament meeting start time at 9:00 am that says sacrament meeting starts at 1:00 pm in 2008.

It really looks stupid, but at least folks are coming to the correct sacrament meeting, even if they do comment about the LUWS.

Larry Jackson

[lajackson]

I spoke with the MLS help desk this afternoon.

If you have set the change with a date in the future and then done a Send/Receive in MLS, there is nothing more you can do, according to the help desk. It does not matter how far in the future you set the effective date, as long as you do the Send/Receive before that date.

CHQ is aware of the glitch in the system and is trying to correct it. The help desk said there is nothing further to do. Resetting the time and doing another Send/Receive will not solve the problem.

The help desk said that the problem is with "a few select units" and that they are trying to solve the problem. The help desk did not have any idea when the problem would be solved. The help desk said it was not possible to correct an individual unit manually. We would just have to wait until the problem is solved.

For the unit in our stake that is affected, I added a statement at the LUWS under the meeting times that shows the correct times: "In 2008, this unit meets at . . . " As I said earlier, it looks silly, but since the help desk claims there is no fix at this time, there is nothing more I can do.

The help desk did that we should make sure that the correct time was in MLS, so that when the problem was fixed, the LUWS would update. That seems to indicate to me that they plan to do a sweep of the entire MLS system and check it against the LUWS side to make sure everything is correct. I do not know that for sure. It just seems that that is the only rational explanation possible in view of the direction that the help desk gave me. I hope it is correct.

It is nice to know that only one of the 14 units in our stake is in such a special category that the interface does not work, although I wonder just what is so special about that unit.

Larry Jackson

[jbh001]

It is nice to know that only one of the 14 units in our stake is in such a special category that the interface does not work, although I wonder just what is so special about that unit.

Although CHQ seems to have already discounted it as an MLS issue, I would be tempted to do two things:

1. Even though MLS is has already likely been patched to 2.8.1, I would download the complete version of MLS and reinstall it so that I would NOT be using a version that had been incrementally upgraded.

2. After doing that, I would backup the MLS database, and then restore the database from that backup. In a different thread someone asserted that doing this forces MLS to rebuild its indexes. After doing the backup and restore, then I would change the meeting time in MLS to something different from what it currently is in either MLS or LUWS and with an effective date 2-3 weeks in the future, then do a Send/Receive Changes.

After that I would wait on CHQ to fix the glitch (if it still persists).

Edit:
I guess I would be tempted to do one other thing before step 1. Since MLS uses Java, I would make sure that the computer in question had only ONE installation of Java and that that version was Java Version 6 Update 3 or later.

I recently ran into a situation where a VPN client that uses Java started taking forever to load and authenticate. When I navigated (in XP) to Start > Control Panel > Add/Remove Programs, I found at least 5 different installations of Java including the current one (keep in mind this was on a laptop, and not a church computer). When I removed/uninstalled all versions of Java except the most current one, the problems with that particular Java application went away.

[lajackson]

There are two units on the computer. The other unit updated just fine.

Well, in late January when everyone else updated just fine.

Larry Jackson

[jbh001]

So much for that theory. I still might be tempted to try step two for the affected unit.

[preston.baxter]

The help desk said it was not possible to correct an individual unit manually. We would just have to wait until the problem is solved.

Not trying to stir the pot here, but when I called CHQ they DID force a manual time change, and now our webpage shows the correct time. This change was not due to any MLS or other LUWS inputs on my part (all my attempts failed). It was due to a change initiated at HQ.

We were one of those "special units," but now I'll have to wait until next year to see if we retain that categorization.

Preston

[russellhltn]

Edit:
I guess I would be tempted to do one other thing before step 1. Since MLS uses Java, I would make sure that the computer in question had only ONE installation of Java and that that version was Java Version 6 Update 3 or later.

Correct me if I'm wrong, but doesn't MLS install it's own copy of Java in a non-default place and in such a way that it doesn't show up in the add/remove?

I understand your point of having only one copy of Java. (The way Java deals with "updates" is a real annoyance in my book.) But I think MLS plays differently.

[jbh001]

You may be correct. I have noticed that installing MLS doesn't seem to affect the version of Java that is installed, but I was attributing that to the possibility of MLS simply checking to see if an adequate version of Java was installed. Now that you bring up that other possibility, I don't know which scenario is actually happening.

EDIT:
I went to test this and found that on my test machine with MLS, no version of Java shows as being installed, yet MLS runs fine.

Upon closer inspection I discovered that MLS 2.8.1 installed its own version of Java 1.6.0.1 (Java Version 6 Update 1) in a way that only MLS knows where to find it.

So it appears that you are correct, and my MLS--Java suppositions are moot.

[lajackson]

Not trying to stir the pot here, but when I called CHQ they DID force a manual time change, and now our webpage shows the correct time.

I am well aware that they could do that if they are willing. I am also aware that multiple calls to the help desk will provide multiple answers.

This is not an issue I have decided to press. I have other fish to fry right now. [grin]