[ryerson_index] Re: Death Dates more than a month behind publication

  • From: Shari-Lei McLean <shari.darkin@xxxxxxxxx>
  • To: ryerson_index@xxxxxxxxxxxxx
  • Date: Sat, 07 Jan 2017 08:52:26 +0000

When the date is entered where the month is the one previous, upon starting
the next notice the cursor appears in the month. I certainly think I've
missed fixing them but I try and make a more conscious effort to double
check as I'm typing


On Sat, 7 Jan 2017 at 5:43 pm, Dawn Montgomery <
billyblue1802@xxxxxxxxxxxxxxxx> wrote:

John

It can be bypassed when you just click on yes when it asks is this
correct.  I’ve done it myself, quite sure I typed the correct thing, and
only picked up my error on checking before putting the file in the Dropbox.

Maybe there could be a second query if, when the indexer says yes, it asks
‘are you sure?’

Dawn M



*From:* ryerson_index-bounce@xxxxxxxxxxxxx [mailto:
ryerson_index-bounce@xxxxxxxxxxxxx] *On Behalf Of *John Graham
*Sent:* Saturday, 7 January 2017 3:19 PM
*To:* ryerson_index@xxxxxxxxxxxxx
*Subject:* [ryerson_index] Death Dates more than a month behind
publication



When I run the update each day, I see about 10 or 15 messages for entries
where the death date is more than 30 days prior to the publication date. I
generally accept them without investigation, because I know that the
indexer gets a warning message when the record is being entered, and has to
consciously accept the message - so surely the date must be correct.

However, two entries in a file today now have me wondering if there is a
fundamental problem in the indexing program which lets these errors through
un-noticed by the indexer.

This is the situation from today. There were three consecutive notices,
notice A with a death date of 22 Dec 2016; notice B with a death date of 1
Jan 2017; notice C with a death date of 2 Jan 2017.

The data as submitted had the death date for notice A correct; notice B
was submitted as 1 Dec 2016; notice C was submitted as 2 Dec 2016.

I'm guessing that the indexer was using the date picker to enter the date,
and because the date in notice A was genuinely Dec 2016, then the indexer
didn't notice it was the incorrect month and year when entering notice B,
and again for notice C.

But in any case, the indexer would have received a warning message that
the death date was more than a month before the publication date for both
notices B and C - and that message is there specifically to trigger alarm
bells so that the indexer has to think as to whether or not the date
entered is correct. It takes a conscious action to accept the message.

How on earth do these sorts of errors get through? Can anyone enlighten
me? Is there a method of entering the date which somehow bypasses the
warning message?

In the past, I have always accepted such dates (I also get a warning when
running the update) on the basis that an indexer couldn't possibly make two
mistakes in the entry (month and year), and then accept the warning
message, if all three were wrong. Seems I am the one who is wrong, to
assume that.

This is problematic as I see probably 10 or 15 such messages in each day's
updates. I don't have time to hunt down the notice and check each one, I
just accept them because of the warning message that I know the indexer has
accepted. But how many of them are wrong?

Can anyone explain how such results could be obtained, short of the
indexer being on auto pilot (and as these three notices were in the first 5
for the day, that's hardly likely.)

John







------------------------------













[image: Avast logo]


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>






This email has been checked for viruses by Avast antivirus software.


www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>











Other related posts: