for a questionaire model:-
using radio buttons is no bad idea, as ranman says you can assign a numeric value to the radio buttons, and the option group will use that value when stored in the db.
depending how the app is to be used there are different techniques. if its a small userbase and probably results put in slowly by individual users,then having something that looks pretty (using radio buttons and so on may be fine),
if you are using data entry typists to 'bang in' results from say a paper then radio groups and prettiness count for nothing, what matters is speed of data entry. in that case use a single text box for each question and get the users to type in a numeric value (eg 0 = N/A, 1 = NO, 3 = Yes).
you can get back to the 'real' data by using IIF's to reprocess the data in a query.
if you use combo boxes, list boxes and radio buttons/option groups then your data can be validated as you do the data entry and you know the values are good. if you use the text box approach and data entry banging in a single number per question then you need to enforce data validation (either in the form [control or form before insert] and or the table [ as part of the column definition)
dont be tempted to give column names longwinded names such as "task A completed", instead use, say Q01 (or Q001 if there may be 100 or more questions)
mind you you should also take note of the the Access rteserved words and symbols and not use those in your tabel and column names (so no spaces in columns/tables).
one reason to be terse with your column names is that the eye is very good at spotting patterns so calling columns Q001,Q002 and so on is easier to spot (certain ) typos allowing you to copy and paste fragments of queries
say you have a table with the responses as a single (integer value)
select iif(q1 = 0,1,0) as Q1_NotApplciable,iif(q1 = 1,1,0) as Q1_False,iif(q1 = 2,1,0) as Q1_True....
then use that query as the feedstock into your summary
select sum(q1_NotApplicable) as sum_q1_NA, sum(q1_False) as sum_q1_F, sum(q1_True) as sum_q1_T.....
then in a form or report, or query if you prefer
%respondents = ((sum_q1_t + sum_q1_f) / (sum_q1_t + sum_q1_f + sum_q1_Na)) * 100.0
%true = (sum_q1_t) / (sum_q1_t + sum_q1_f + sum_q1_Na)) * 100.0
%false = (sum_q1_F) / (sum_q1_t + sum_q1_f + sum_q1_Na)) * 100.0
%Not applicable = (sum_q1_Na) / (sum_q1_t + sum_q1_f + sum_q1_Na)) * 100.0
and so on
similarly you can assign a value to a multi choice quetion. often you will se quetiosn such as
Q5: How helpful did you find dbForums
not relevant (0)
Not at all (1)
slightly helpful (2)
very helpful (6)
in this case when you do your summarising
select iif(q5= 0,1,0) as q5-Notapplicable, ....... iif(q5 = 6,1,0) as Q5_VeryHelpful
..and so on.
the only caveat is that a single MS Access query cannot have (IRRC) more than 255 items, its acutally a few thigns less than that. so if you have say 40 questions with six responses then thats 240 columns in your analysis query. if you have say 30 questions with 10 responses then you'd need to split that into analysis into 2 queries to make certain you are under the limit
its also a pig to do the initial queries that do the reformatting, but it is a trade off between data entry speed and accuracy (that must be as fast as possible every time), against time taken to develop, test, debug the query which happens only once
In my dim and distant past I did a customer services questionaire, with IIRC 200+ questions mix of yes / no, multi choice and so on. which required breaking up into lots of analysis queries. being able to use copy & paste for the IIf's was an absolute godsend.
I'd rather be riding on the Tiger 800 or the Norton