# Thread: Building a Report - Set needed?

1. ## Building a Report - Set needed?

Hi All,

I'm working on a report to show the number of early failures based on the total number of product repaired grouped by technician for the prior month.
The report is based on a table that stores all the repair work orders.
I'm 90% there with the report, all the numbers are correct with the exception the total repairs... the problem arises because the report detail is filtered on DOA="Y". This gives me the correct detail records but allow me to help to calculate the total repairs.
The goal is to see the ratio of quantity doa="y" / total repairs.

For Example, the attachment shows the month of September and Technician DL. Looking at Part Number 2320993-R, the total quantity should by 89 (based on total repairs for September). The total DOA is 2 which is correct. We can see the 2 work orders matching that criteria as well.

The red circled areas on the report should show the total of repairs for the month.
report.JPG
report_designer.JPG

Here is the filter:
year(date_in)=year(date()).AND.month(date_in)=month(date())-1.AND.doa="Y"

So my thoughts are:
1)ideally come up with some calculation that does not require an index addition (this table already have too many indexes)
2)create a filtered index, sorted by product so I can place a calculated field on the report and use db_count() to count those records
2)create a set... would probably need a Summarize operation but not sure how to structure it all

2. ## Re: Building a Report - Set needed?

If you are wanting the total of repairs for the previous month for all technicians try this for the calculated field:

tot_repairs = tablecount("yourtablename","(year(date_in)=year(date())).AND.(month(date_in)=month(date())-1).AND.(doa='Y')")

You should be able to test it as a variable in the IW before adding it to the report as a calc.

3. ## Re: Building a Report - Set needed?

Hi Robin, thanks for the reply.
Your calculation looks good, I used without the .AND.(doa='Y') since my report is already filtered on (doa='Y').

So this calc gives me the total for the month, but how can we apply it to the grouping as well (per tech, per product)?
Also, it does take 5-10 seconds to run the calculation, is there a more efficient method?
Capture.JPG

4. ## Re: Building a Report - Set needed?

A very wise old alpha developer said to me that all reports should be based on a set even if there was only one table.

5. ## Re: Building a Report - Set needed?

Tablecount() is based on the table outside of any other filters in the report itself - so it works for the number circled in green using its own filter. I am not sure what you want the numbers circled in red to reflect. Is it the count of the records in the group or a percentage of the total?

I would test the query on a browse view of the table and check the STAT button on the toolbar. With the query in place you can resort or use quick filter on whichever field you want to test. A sample table would help us help you...

6. ## Re: Building a Report - Set needed?

Thanks for all the responses so far.
Robin, the numbers circled in red and green are supposed to reflect the total counts of repairs.
So the green one is working correctly, it is the calculation you suggested (although it does take a bit of time for the form to run this)
Next, I'm looking at the red circled fields. These are counts based on the report grouping (Technician -> Product)
In the photo, "DL" is the technician, and 3 products repaired by that technician are below him (underlined in red).
We can we see the total # of units that technician repaired as well as the breakdown per product.

7. ## Re: Building a Report - Set needed?

If you use a script to run this report you can get the tablecount() info into a global var and display that var on the form, which might be faster.

Is there a condition where DOA would NOT equal FOA?

8. ## Re: Building a Report - Set needed?

Originally Posted by DaveM
A very wise old alpha developer said to me that all reports should be based on a set even if there was only one table.
Words to report by.

9. ## Re: Building a Report - Set needed?

Al - I know you wrote about the reasons for that in here somewhere, could you provide the link for why we ought to do that?

10. ## Re: Building a Report - Set needed?

Originally Posted by MoGrace
Al - I know you wrote about the reasons for that in here somewhere, could you provide the link for why we ought to do that?
I am not aware of a single link or a series of links that would explain a relatively complex topic like that.

Some ideas I use to help with it are:

1. Most reports that are based on a normalized data structure are going to be in a set anyway.

2. While table relationships can be handled in multiple ways, the set linkages are usually more efficient.

3. A report usually needs a different set to hold different but similar relationships than a form or browse that does data entry. That said, I use a browse based on the report set to help me 'see' the data the way the report does. That really helps in multiple one to many relationships. Showing the data from key fields and linkages shows me where issues might be.

4. External data sources that are imported or passive linked tables can overwrite the support files for that table, but won't touch the support files for a set. Therefore a report(or other objects) stored in the table support files won't disappear when the data is refreshed and the support files overwritten with new ones.

5. As a carry over from older versions, transporting the support files for a set was/is a good way to move a report from development systems to production. The export/import a report(or other objects) has lessened that need.

6. Sets are a very powerful tool in the Alpha toolbox. Moving forward from dbf to relational databases, views are a natural progression from the set concept and should be used there also.

Like all tools whether software, hardware, word working, metal working, etc... all have a purpose that may or may not work in a specific circumstance.

We could collectively build reasons for the use of an Alpha tool. Please feel free to add to this list or present caveats.

11. ## Re: Building a Report - Set needed?

Thanks, I think it was #4 I was thinking of.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•