Good suggestions all around. I would include the suggestion of making the field that holds the user's answers an integer and using the VFP bit methods (i.e. BITSET() BITTEST() and BITCLEAR()) to work with that field. This would allow a high degree of scalability - for instance: multiple choice answers and even if you have a large number of possible answers it will handle it. Also, you'll want a few lookup tables that will hold the questions and which bit each answer corresponds to (such as Good = 0, Fair = 1, Poor = 2... these are which bits are set to indicate the user's judging). The only drawback to this approach is that it makes databinding a bit more difficult.
>>hi all,
>>what is the best way
>> to create a table have fields with data as under
>>ex..
>>
>>q1. what is your contract type
>>
>> 1.personal offers/prepaid card 3.companies offers/prepaid card
>>
>> 2.personal offers/postpaid card 4.companies offers/postpaid card
>>
>>q2. based on your past exprince with tel.company how you judge the following?
>> good fair poor
>> ---- ---- ----
>> 1. price 1 2 3
>> 2. service quality 1 2 3
>> 3. after sales services 1 2 3
>> 4. billing 1 2 3
>>
>>
>>
>>thanks
>
>q1 might be a single field, either character or numeric (1 byte), to store the four options, coded with the same numbers you showed, that is, 1-4.
>
>In q2, each of the four parts might be a separate field, also 1 byte.
>
>If you think that in the future you might expand to more questions, or in general, to accomodate a variable number of questions, it might be better to have a separate table, with the following fields:
>
>First, in the main table, you would have to add a primary key, with a unique value for each person included in the survey.
>
>In the secondary table, you would need a link (foreign key) to main table. Additional fields would be the question type (coded in a separate table, which lists the different questions), and the value stored for each, i.e., the reply.
