Hi David,
It looks like you are well on the way to having this problem "cracked". In reading your response I have the following replies/comments:

I should say that our survey app was very simple (and built in Fox26) so we couldn't take advantage of all the new and wonderful features of VFP.

Do you really need a record in the child table for each possible answer? I haven't quite got my head around that one (I guess Dr Codd would be proud of you).

I think your branching rule (i.e. no default) is more robust than mine - the only problem is that you kind of have to work backwards since a question definition will not be complete until you have defined which other question to branch to (which may not yet be defined????)- tricky...

If I was doing it again today I would definitely look at some kind of Visual Survey Builder i.e. use drag and drop to build a schematic map of what the survey would look like (a bit like a flow chart). I would need a Start, Stop, Question boxes and Link lines. This would allow the survey creator to view the survey logically (as a Network as you suggest).

The 'skip if not accessed by branching' is a key part to the 'fall through' strategy - it avoids falling through to an inappropriate question - again I have to agree that your strategy sounds superior.

Our numbering system is a very general ID that we used in many tables consisting of a year plus a counter string eg '99-00001'. (We are now rapidly moving away from this for new VFP apps and using integers instead.) The fall through doesn't really rely on the IDs it justs plods through the whole table (skipping those that are 'skip if not accessed by branching'). We have only used the survey in a limited (internal) way - it certainly wasn't intended to ship to external customers.

I guess that if you come up with a great app, who knows, maybe you will be administerinng 999999 question surveys!!! I'd be pleased to see it when it is finished.

Good Luck
Sam