Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Counting Checkboxes

Status
Not open for further replies.

Steven547

Technical User
Sep 15, 2004
165
US
I have a form, which originally had 10 checkboxes. Each box was named: box1, box2 etc. I had a function that if the check box was checked, it counted (box = box +1). Then it gave a percentage (because there were only 10 boxes, it would be for example: final box count / 10 for the percentage completed.)

However, my company just decided the don't want 10 boxes (tasks to them), but they want 30 additional. Is there an easier way to record the tasks completed, other then coding for 30 different boxes? If they they check 15/30 boxes, the percentage will be 50%, etc. And this will be done on the fly (probably on the current event so as they check a box, the percentage changes instantly.)

Thanks.
 
Have you read
I suggest you use tables:

[tt]tblTasks
TaskID
Task

tblJobTasks
JobID ) each to be a foreign key but combined
TaskID ) as the primary key
DateCompleted[/tt]

tblJobTasks becomes the basis of a subform of the form based on tblJobs. Completed percent can be calculated in the subform footer. Tasks to be completed can be selected when the job is created.
 
You're suggesting to use 2 tables? I created one table with TaskID as the primary key. These are just "yes/no" responses. I'm confused by the 2 table suggestion?
 
Basically, it's going to be:

1 Liaison Identified? yes no <--check boxes
2 meeting completed? yes no
3 exported? yes no

There will be about 30 of those...
Then a percentage complete (total checked yes / total tasks)
 
You're suggesting to use 2 tables? I created one table with TaskID as the primary key. These are just "yes/no" responses. I'm confused by the 2 table suggestion?"

And this design is not correct for an Access table. This is why you are having problems expanding your table, forms, reports, queries, etc.. Access is a RELATIONAL database system, not an Excel List. You must NORMALIZE your tables, thus the references to the article. Your table violates the first normal form: you have repeating column headings - task1, task2, task3, etc.(no matter what you called them). This will lead to empty cells in the table, not appropriate in Access. This then causes variable length records. And looked what happened when you needed 30 more, problems. What would happen with 300 more? A table can only hold 256.
And, finally, your individual tasks make up a category. You have a table within a table. Can't happen in Access. So you should only have a single field called Tasks. Then construct the one to many tables to record completions.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top