Tech Forum

How could a clerk generate a list of those who are members but not active in the ward? Is this possible?

One thing we have done is our ward is to use the MLS export files to construct a custom query a little more complex than what MLS supports directly. It takes some basic database skills, and can be done in a program such as MS Access or OpenOffice Base.

The logic we use is by family. It also can be adapted to individual members. The rule we follow is that if anyone in a family serves in any calling, or as a home-or visiting-teacher, we treat that as a rough proxy for active. Not perfect, but a very useful indicator.

boomerbubba wrote:The logic we use is by family. It also can be adapted to individual members. The rule we follow is that if anyone in a family serves in any calling, or as a home-or visiting-teacher, we treat that as a rough proxy for active. Not perfect, but a very useful indicator.

If you want to use the calling criterion for individuals, it can be done simply in MLS using the Members without Callings report. If you need to adjust that, use a custom report that filters the individuals using "Calling Position" "has no value", and whatever additional criteria you may want.

That's even less perfect, but it can be done by any clerk, even without database skills.

Alan_Brown wrote:If you need to adjust that, use a custom report that filters the individuals using "Calling Position" "has no value", and whatever additional criteria you may want.

That's even less perfect, but it can be done by any clerk, even without database skills.

IIRC, the clerk could even embellish that by adding custom-report criteria for members who also are not home teachers or visiting teachers. (He would be using database skills even if he didn't know he had such skills. ) The criteria also could exclude non-adults and non-members. I'm not in front of an MLS computer at the moment, so I may be mistaken about some of that.

The main difference between that custom report in MLS and the external SQL query I described is that my query is broadened to households. If what zaneclark really wants is individual members who are inactive, the MLS custom query might suit his needs well.

boomerbubba wrote:IIRC, the clerk could even embellish that by adding custom-report criteria for members who also are not home teachers or visiting teachers. (He would be using database skills even if he didn't know he had such skills. ) The criteria also could exclude non-adults and non-members. I'm not in front of an MLS computer at the moment, so I may be mistaken about some of that.

That's only sort of true. The challenge is that you can't do OR's or certainly not more complex conditions on a custom report. So you can't include people who are (if they are male, not a home teacher OR if female, not a visiting teacher). But you could create two separate reports (one for male, one for female), and then put the results together.

Your male custom report could be:

Age -- is or is greater than -- 18
Calling Position -- has no value
Sex -- is -- male
Home Teaching -- is not -- Assigned as Home Teacher

And then your female custom report could be:

Age -- is or is greater than -- 18
Calling Position -- has no value
Sex -- is -- female
Visiting Teaching -- is not -- Assigned as Visiting Teacher

Perhaps some could come up with a clever way to do this in one report, but I can't think of how it can be done.

Alan_Brown wrote:That's only sort of true. The challenge is that you can't do OR's or certainly not more complex conditions on a custom report. So you can't include people who are (if they are male, not a home teacher OR if female, not a visiting teacher). But you could create two separate reports (one for male, one for female), and then put the results together. ...

I think you could just leave gender out of it, using ANDs but no ORs:

Age -- is or is greater than -- 18
Calling Position -- has no value
Home Teaching -- is not -- Assigned as Home Teacher
Visiting Teaching -- is not -- Assigned as Visiting Teacher

boomerbubba wrote:I think you could just leave gender out of it, using ANDs but no ORs:

Age -- is or is greater than -- 18
Calling Position -- has no value
Home Teaching -- is not -- Assigned as Home Teacher
Visiting Teaching -- is not -- Assigned as Visiting Teacher

Obviously that would work, since we are dealing with "is not" criteria. Thanks for correcting my (hopefully temporary) brain cramp!

I think the baptized criteria also needs to be added. MLS can include non-members, and zaneclark specified "those who are members but not active."

BTW, it occurs to me that when we are sharing ideas for custom MLS reports, it might be helpful for someone to create those report definitions in MLS and export them. The report-definition files then could be posted here, and imported to the user's MLS system. I've noticed this feature in MLS but never used it.

boomerbubba wrote:I think the baptized criteria also needs to be added. MLS can include non-members, and zaneclark specified "those who are members but not active."

Actually, that is not necessary. Non-member records do not have a birthdate, so the Age >= 18 criterion excludes them. But it wouldn't hurt to add criterion "Member status -- is -- Member" just to document in the report itself that you intend to exclude non-members.

boomerbubba wrote: BTW, it occurs to me that when we are sharing ideas for custom MLS reports, it might be helpful for someone to create those report definitions in MLS and export them. The report-definition files then could be posted here, and imported to the user's MLS system. I've noticed this feature in MLS but never used it.

Good idea. The report file is just a simple XML file (with an .MLS extension). I have attached one to this post that meets the criteria we have discussed (but I had to tack on a .txt extension so the forum would allow it to be attached -- remove the .txt before trying to import it).

Excellent.

As a final footnote, in case anyone with influence is following this idea: It illustrates one more reason that destroying the integration of HT/VT data with the rest of the membership data would have a big downside.