Tech Forum

One of the wards has a failed MLS (database errors) that cannot be repaired by restoring from a backup or even a clean reinstall of MLS. SLC has "been working" on this issue for a week now and the problem has been "sent to the programmers" but they have not communicated anything at all with me. I do not want this ward to be without MLS for a 2nd Sunday in a row, so how can I at least get them up and running? Should I install MLS on a laptop and use that as a backup until the original is working? What happens to the ward's data if I create a "new" ward with this unit's ID # but don't restore any of the backup files before entering donations that the like?

The sooner I know what to expect the better - if I am going to be recreating a "new" ward I am sure that I will need to call SLC to get the security token reset before Sunday.

Also, does anybody have any direct contact information to the department/people who should be helping with this? Lack of communication or visibility makes me wonder if they understand just how critical this issue is.

If you have validated it can be restored on a separate machine, then I don't understand why we can't get it going on that computer.... Just need to clear everything out of the local computer.

For now, seek the advice of the Stake President and follow his direction.

aclawson wrote:I do not want this ward to be without MLS for a 2nd Sunday in a row, so how can I at least get them up and running?

Honestly, I don't know as you have a choice here. And they're not the first that's been in that position - nor the last.

aclawson wrote:Should I install MLS on a laptop and use that as a backup until the original is working?

Small matter of installing MLS on a personal machine.

aclawson wrote:What happens to the ward's data if I create a "new" ward with this unit's ID # but don't restore any of the backup files before entering donations that the like?

Unless someone else has tried it, you're in uncharted territory here.

aclawson wrote:The sooner I know what to expect the better - if I am going to be recreating a "new" ward I am sure that I will need to call SLC to get the security token reset before Sunday.

More like end of work - TODAY. I'd say that's about 2-3 hours from now.

aclawson wrote:Also, does anybody have any direct contact information to the department/people who should be helping with this? Lack of communication or visibility makes me wonder if they understand just how critical this issue is.

You'd be working though Local Unit Support. While it's not desirable, I don't know as I'd call it all that "critical". Certainly not critical enough to risk messing things up worse.

Instead I'd pull together the information needed on how to survive without a computer - things like Emergency Check writing procedures and how to do the deposit.

JohnShaw wrote:If you have validated it can be restored on a separate machine, then I don't understand why we can't get it going on that computer

The restore from file works without any trouble and I can do exactly one send/receive - which then loads some patches and whatnot and says I have to log out and back in again, but when I go back in I get all kinds of database read errors and messages saying that there isn't enough room on the disk.

SLC says they have received the backup files and that nobody has ever seen this problem before (this is my talent - perhaps my only talent in the world, and that is to attract the weirdest and strangest errors that nobody else will ever see) which is why they had to send it to the programmers.

For kicks and grins, you might want to download Memtest86 and run a diagnostic on that machine. Bad memory can cause the strangest things.

I was once trying to fix a friend's computer. I gave up and tried to reload from CDs. The computer declared the ZIP files on a mass-produced CD as corrupt. That's how I found out the machine had defective cache memory. All in all, the machine ran amazingly well and the problems were repeatable for that big a defect. It kept fooling me into thinking it was software.

I have proven that the problem is with the data file - installed MLS on a new machine, copied over the \ProgramData\LDS Church directories (and by trying to restore a file) and I get the same database errors.

SLC has known about the problem for a week and never touched base with me once. Too busy? I can understand that. Bigger problems that they care about more? I can understand that, too. But completely ignoring me, refusing to discuss the problem with me - that is not an acceptable way of doing things.

So meanwhile I have a unit that has no MLS - the system is broken, there does not appear to be any way of fixing things locally and I am getting no support from SLC. So what should I do now? Should I delete the data directory and just start to use MLS as a brand new ward starting out with no data at all?

If anybody has any idea of how to work around a corrupted datafile (one that was corrupted weeks ago, definitely before the latest update to MLS so simply restoring from a backup is not going to work) could you please let me know? I have no choice but to start to experiment and try to come up with my own procedure here.

Well, that didn't take long - in the process of attempting various backups/restores I am now locked out again and need another security reset. So this guarantees that this ward will be unable to use MLS for a second week. Meanwhile, I was able to capture two new families that were transferred into the ward so they won't be missed, but until SLC gets around to fixing this problem (a week? A month? Never?) everything is completely shut down.

aclawson wrote:SLC has known about the problem for a week and never touched base with me once. Too busy? I can understand that. Bigger problems that they care about more? I can understand that, too. But completely ignoring me, refusing to discuss the problem with me - that is not an acceptable way of doing things.

I have considerable sympathy for you in this regard. It has been my experience that a stake clerk or an STS is not someone that the helpdesk considers a valued partner in the experience - this experience communicates it loud and clear (whether it is intended, implied or completely wrong) SLC must find a way to fix this.

JohnShaw wrote:

aclawson wrote:SLC has known about the problem for a week and never touched base with me once. Too busy? I can understand that. Bigger problems that they care about more? I can understand that, too. But completely ignoring me, refusing to discuss the problem with me - that is not an acceptable way of doing things.

I have considerable sympathy for you in this regard. It has been my experience that a stake clerk or an STS is not someone that the helpdesk considers a valued partner in the experience - this experience communicates it loud and clear (whether it is intended, implied or completely wrong) SLC must find a way to fix this.

Wow, that hasn't been my experience at all. I have never had the help desk "refuse to discuss" a problem with me. I've always felt that there was a sincere desire to help me. On occasion I've been frustrated at the quality of the help, but never about the desire to give help.

Just as with any support organization, the Global Service Center has some people who are more experienced and capable than others. And just like any other support organization, there is a hierarchy and options to escalate issues to managers if you are not getting the support that you feel is appropriate. I'd recommend that if someone refuses to help you, you should kindly ask to speak to their manager.

It isn't that the -help desk- wasn't willing to help, *THEY* were great. It is the programmers above them who don't seem to care in the slightest.