Ensuring accuracy of reported data

[ITCPhil]

((**If something similar has been posted, I could not find it with my search terms**))

Hi there,

I am posting this for myself, but I am sure a lot of other folks will appreciate whatever answers are posted in the thread.

What I am looking for is helpful tips and hints that folks use to ensure that their reports are accurate. I am sure we have all gone over a report at some point and noticed that our data was incorrect, either by an error we made or someone else.

How do you all go about making sure your report data is as accurate as possible and not faulty?

For myself, I really can't say I have a method of doing this. I report based on a call center environment so I will usually report on 1 day only and grind the numbers manually, but it took me 6 hours today to go through a fraction (around 2%) of the incidents so it is not always a plausible method to use and I told myself, 'surely someone out there has a much better method than this' so here I am...

Thanks!
ITCPhil- who found out today a report was inflating results by up to 50%, ouch!

 

[synapsevampire]

Wonder what grind the numbers means...

Ensuring data integrity is best served by a database process, rather than a report writer, although you can use either.

Of course there are rules to this, and your front end coders should have insanity checks on basic fields, such as dates, values, addresses, phone numbers, etc.

A report might be designed to pull back funky data by using the record selection formula, such as:

(
isnull({table.date})
or
datediff("y",{table.date}, currentdate) > 100
)
or
(
isnull({table.value})
or
(
{table.value} < 0
or
{table.value} > 1000000
)
or
(
len(trim({table.phone})) < 7
or
isnull({table.phone})
)
...you get the idea...

There are lots of potential rules. I assume that reminiscing over the lovely 6 hours of grinding numbers will help you uncover them.

Once the report returns the bad data, you can correct the data in the database, and take steps to improve data quality.

-k

 

[ITCPhil]

Grind the numbers equals printing all incidents, taking out a calculator and doing it all manually. Most folks use SQL I gather.

 

[Turkbear]

Hi,
As synapse pointed out, the report stage is too late to start cleansing the data...So if the contents are bad, the output will be bad..There are tools for data Quality checking, assuming there are business rules you can define to tell what is 'bad' data..

However, designing a report on perfectly good data can return bad results as well..This is usually caused by the report designer being unfamiliar with the data and its iter-relationships, or not being skillful enough with Crystal to get out what they want..Training,a good set of 'best practices' and good meta-data documentation can help avoid most of those kinds of errors...

Be aware however, that as long as humans design reports, some will be incorrect...





To Paraphrase:"The Help you get is proportional to the Help you give.."