Disk-Based Field Questions (DBR)

Disk-based FIELD questions allow you to have up to 32,000 categories. They are called disk-based because the question is compiled separately from the questionnaire and the response list is stored as a separate file on the disk.

The syntax for a FIELD question using a disk-based response list is:


Only subtype USE_PREVIOUS_ANSWER is allowed; HIDE_RESPONSE_LIST is ignored. The question must be single-response. This question type does not work with HIGHLIGHTCATS mode.

If no subtype is specified, the question is displayed on the screen by level, and will return a final code after all of the levels have been asked. You can use this with a FIELD subtype USE_PREVIOUS_ANSWER to associate text with long lists of product codes, quota subgroups, etc.

To do a similar function with multiple responses (multiple levels), see the OUTPUT= response list option.

The file name can be any valid file name (starting with a letter), with or without an extension. By default it uses an extension of “dbr”. Use “$filename” to refer to a file with a different or no extension.

An example of a use for this would be when asking about a product with model numbers within car brands. The part of the list referring to the brand would be displayed first. Then, the model number sub-level would appear. The code stored would be a unique code that identifies the brand AND the model number.

During interviewing it may be necessary to change a long list, for instance, to accommodate unexpected mentions that are falling into “miscellaneous.” With a disk-based FIELD question, you can change the list while interviewing is going on without having to re- compile the whole questionnaire.

Designing and Compiling the Disk-Based Response List File

You compile a disk-based FIELD question response list with the command:

OUTPUT=filename, ENTRIES=##

You can also spell DISK_BASED_RESPONSE_LIST out as DBR. The next statement after this would be “OUTPUT=filename”, specifying the name of the disk file that will hold the response list.

This must be the same name that you have on the FIELD question statement in the questionnaire. You may have as many references to the same file as you would like in the questionnaire, and can have as many different disk-based response lists as you would like. If you have more than 1000 expected codes in the DISK_BASED_RESPONSE_LIST file, you must specify the number of entries by saying “OUTPUT=filename, ENTRIES=#” where # is the number of codes. Although we have used the extension DBR in the following example, the extension is optional and, if specified, can be any valid name. The equal (=) sign on the disk-based recode table OUTPUT statement is optional; a space will also work.

This file is written with levels. An item in the list may have other levels beneath it. The item of a path must have a code to be put into the data. Codes must be the same length and may be up to 20 characters long. There is a limit of 10 levels. Each level must fit on the screen if it is presented; this restricts the number of items allowed on a level.

When going live, the .DBR file needs to go into the $CFMC/QFF directory.

Each level is lined up starting in the same column. A new level must be indented at least one space in from the previous level. There is special syntax to print text for a level, and other controls.


     01 IBM
001       A 360
          B 370 Testing
002         X- 1
003         Y- 2
004         Z- 3
005       C 1130
          AA 3000
006         1 II/III
007         2 3X
008         3 4X
009           A 64
010           B 68
          BB 900 Series
011         1 925
012         2 935
013         3 Other
014  03 PERTEC
015      AAA MODEL 1
016      BBB MODEL 2
??? Unmatched code in data


The first level of this response list is 01 IBM, 02 HEWLETT PACKARD, 03 PERTEC, 04 MISC, and ??? (a no match item). Code 03 is a terminal branch, 04 has one sub-branch, 01 has two subbranches, and 02 has three sub-branches. Also, the response code items may contain back references to previous questions, screen enhancements, and skips to other questions. The terminal codes are listed starting in column one.

You will often need to put text on the levels of the response list. This is done by putting an exclamation point (!) and the text above the first response code of a level. There may be up to 20 lines of text per level (after the initial text for the question). You can use any of the text control statements to position the text, start a new line, highlight words, etc.

When the response to the question is later displayed, you will see the text from all of the levels responded to. You can keep a level’s text out of the back-reference by putting a dash (-) in the space after the response code, as in X, Y, Z, 4 and 04 above. Answer text is concatenated for each level if necessary. The maximum answer text may not exceed 159 minus the number of levels. If it is longer, the error “no space for answer text” will print in Survent.

The ??? syntax as a terminal code allows responses in the data that don’t match the other provided codes. This is so that data that has been pre-coded can be allowed into the questionnaire without rigid checks, which would be very difficult on a large list.

The END statement must be the last statement in the file before the ~END.

The FIELD question that uses this response list looks like this:


What is the computer you use most often?

You must specify a data width; since the response list is compiled separately, PREPARE has no way of knowing how many columns to allocate unless you tell it. Neither PREPARE nor Survent will complain about a bad width. PREPARE will give an error if no width is specified.

The text from the question would display first followed by the text for the first level and its response items and so on.

When Survent is run on the above example, the question would first display level one items (01, 02, 03, 04). Typing 04 would display a second response list consisting of AAA MODEL 1 and BBB MODEL 2.

Here is another example with text on each of the two levels:


     01 IBM
       !IS IT A 360 OR 370?
001    A 360
002    B 370
       !1, 2, OR 3?
003    X- 1
004    Y- 2
005    Z- 3


There is no way to continue text in a disk based response list by using &, but the spec file can have up to 5000 characters per line.

SKIPTO may be specified preceding the text but indented for that level.


!This text will print at level A
     (box spec) text and screen position for items at this level
     0 LEVEL2 Under A
A0XX            XX - LOWEST ANSWER
A0YY            (SKIPTO label) YY HIGHEST ANSWER

Note that the SKIPTO is indented correctly for this level.

To update (i.e., compile a disk-based FIELD question with reference checking) an already compiled QFF file with your disk-based response list:

~QFF_FILE <studyname>
&specfile (or have actual specs here)

You can also put your DISK_BASED_RESPONSE_LIST compiles at the end of your regular compile.

… questionnaire specs …
… DBR specs1 …
… DBR specs2 …

On conditional statements, you cannot have references to DISK_BASED_RESPONSE_LIST code lists, such as DBR1(001-004); they are too long for the program to store in memory. Instead, use [#] or [$] references; for example:

!IF [DBR1#001-004] 
!IF [DBR1$“AAA” - “AAZ”]

Pre-loading Responses in Disk-Based Recode Lists

Pre-loaded entry strings may be used; this means that you will be able to load (part of) a DISK_BASED_RESPONSE_LIST response, and be set up in the DISK_BASED_RESPONSE_LIST at the point where you have pre-set to. This is most useful if you have a sample file that may have some initial product information and may not, such that you could skip people through the initial screens if you had the data for that already.

The entry string can include direct response codes or back- references to the data of other questions. The syntax is:

!FIELD,subtype,MAXIMIM_RESPONSES=#,DBR_FILE_NAME=<name>.DBR,<\|label|stuff\|label2|junk,\|label3, etc.>

Commas are discarded and are acceptable separators; spaces are not. Each part separated by commas will be treated as an answer to one screen of the DISK_BASED_RESPONSE_LIST. You must back-reference the data of the prior question (using\|label|), because that is what is being accepted as the response, not the text of the response (\:label:).

NOTE1: When interviewing, you can use the caret (^) to walk back up a path to possibly go down another one, or even to get out entirely to the question before this one. You may also use the other interviewer keywords.

NOTE2: You do not have to recompile the specs for your main questionnaire, and you can update the DISK_BASED_RESPONSE_LIST when the QFF file is being accessed.