Barbara,

Thanks for your reply. I will email you separately with some of the details and design issues that I am facing. Or, if you have the time, you can call me at
908-526-6665 x201, collect if you want.

Here are a few of the major issues:

Here are the basics of my database design (there's more but..)
For the survey 'definition' - a table called surhdr - with a survey id
For the questions 'surques' - 1 Row per question
For now I only support text/numeric answers and multiple choice/pick one only
types. Ultimately, I need to support 'pick more than 1', and need to support
questions that represent a score, scale or rating, eg. add up a score for
level of agreement - 5 - agree strongly 4 - agree 3 - disagree 2 - strongly disagree - get an agreement rating.

So I have a table - surans - one row per possible answer with the answer
text. If it is a text or numeric answer, there is only 1 row in surans
and the answer text is blank

For actual responses to the questionaire, I have:
resphdr - stores date and time taken, what company,person took it
unique id for the 'response data set', and a couple of misc. columsn
respdtl - stores the actual answers given - only stores the answer number
if it is multi-choice, stores the text if it is text/or numeric (don't
differentiate between text and numeric). respdlt has one line per answer
actually given.

I started out with a simple start with q1 - skip to next or skip backwards
logic - easy .

Now trying to handle a more generic 'engine' that handles various types of branching. For now I am storing the 'branchto question #' in
respdtl. Question: should ALL ?'s be defined as branching, eg 1 branches to 2.
or should the logic 'fall through' to the next question if there
are no branching instructions.

Coding a 'network model' questionnaire that allows branching from anywhere
to anywhere seems VERY HARD. How would I check for circular references ?

Coding a 'tree' doesn't seem as hard. In other words, only allow branching
to a new unique question # that no other branch has branched to. A lot of
duplication possibly - if there is overlap. But easier to handle

How about 'deferred branching'. In other words, breaking the questionnaire up
into sections (which I have already done). So in section one, ask a series
of questions. Then, analyze the output from that section, via som
algorithm, logic, rules of thum. Eg. ask about pets:
in section 1- if results are 'pet lover' go to pet lover section, if results
neutral - go to pet neutral section, if hate pets go to pet haters section

Question: In the current 'branch engine' - a 'back pointer' is entered
'on the fly' that records the previous answer. Should the back pointers
be 'hard coded'. If i tried to build a 'network' where you could get to
any question from any other question, then you couldn't hard code the back
pointers

Question: did your questionnaire handle simple branching based on the answer
to a given question, or would it branch based on the sum of some numbers,
or a complex set of conditions, pertaining to the answer to a COMBINATION of
question answers ?

Question: showing one question at a time is easy, attempting to show
more than one at a time, especially if you are handling complicated
branching logic, seems, well, very very difficult. Would need to define
some state logic for what is dimmed what is not. Similarly, allowing for
moving ahead in the question order, and answering questions in any order
seems like it would be almost impossible, in the case where there are dependencies and complicated branching, e.g. allow an answer of a 'later' question, 'earlier', change the earlier, and the dependency force the answer to
be invalidated.

It seems as if moving forward in branch order, predefined is straightforward
but allowing skipping around is impossible.

Even 'backing up' seems a little difficult. If you back up to a previous question. and reset the answer, you need to reset the answers to all dependent questions, and then force them to re-answer, or, optionally, not forc them,
and apprise them that dependent questions have not been re-answered ?


Question: Showing question numbers on the screen - Each question has an
'absolute' number' Also, I have 'sections' and each question has a number within the section. The unique numbers are added, on the fly as I add content,
and have very little correspondence with the actual order of the questionnaire.
It seems to make more sense to just autoincrement a number based on the
order in which they answer, which might vary depending on the branching. But how do I print output ? what number to print - 'relative' number or absolute number'





Another problem - building the interface for asking and answering hasn't been
that hard. But I am hand keying via browse, my questions and answers, I need
a 'build questionnaire interface' - to automate the handling of question #
sequencing - and 'branch as I build'

BTW - I am building a set of radio buttons, and /or text boxs for the answers,
on the fly with 'addobject() in a container.


OK - thats enough for now - hope that wasn't too confusing !!! Looking forward to your reply (and others)


>David,
>I did a program with branching logic a couple years ago - I ended up using a record for each question telling where to go next for each possible answer. It was nasty to set up, but worked beautifully. Feel free to email me and we can bounce some ideas around if you'd like. Or reply here and get EVERYONE posting ideas.
>
>Barbara
>
>>I previously posted this under 'chatter', but got no replies, so I am trying again here under coding. Here is the question:
>>
>>I am designing/coding a VFP based survey/questionnaire program for a client. It is turning out to be very complicated. I'm wondering if anyone has tackled such a project. I'm hoping to share ideas on design, database design. There are commercial programs out there - but none that meet my needs. One - http://www.raosoft.comn uses dbfs - but doesn't quite fit.
>>
>>Trying to make a truly data driven program that handles lots of different branching logic is daunting. If anyone is interested, or has done similar work I will share more details on the particulars of the design issues I am facing, have resolved etc.
>>
>>TIA