When a respondent or interviewer restarts a timed-out interview by clicking Next, the interviewer session engine uses the information in the interview's value cache file to reconstruct the interview as it was at the point it timed out. It does this by reloading all the information in the most recent save point for that interview and then re-executing any statements in the script that exist between that point and the question at which the interview stopped or timed out. When the session engine reaches this question it displays it and waits for an answer.

If the saved portion of the interview has pended quotas these remain as they were at the point this happened. The restart does not check whether the quotas for the pended cells are still open. If some quotas have been filled while the interview is in its timed out state and the interview then completes, you might find that some quotas go over target.

The time-out/stop/restart process can happen more than once during an interview, but as long as the interview's cache file is accessed at least once during each 48-hour period it will remain in the cache. Without manual intervention, files are deleted from the cache only when the interview completes and the data has been copied into the case data database, or when they have not been accessed for 48 hours.

If the interview script has changed since the interview started, the value of the InterviewRestart project property (see Project and interview properties: Reference) determines which version is used to restart the interview. The default is to restart using the latest version of the script rather than the version that was in use when the interview timed out. When restarting using the latest version, the interviewing program replays the interview as described for restarting from a URL (see Restarting from a URL); when restarting using the version that started the interview, the interviewing program uses the information in the value cache as described earlier.

When a respondent or interviewer goes back to an earlier question, the procedure is similar to that for clicking Next to restart an interview. The engine finds the save point for the question that is on the interview path immediately before this question and reloads all the information held in that save point. It then re-executes the script from that point up to the question that the user returned to and displays that question. Any save points that exist after the one for the previous question are effectively deleted from the cache file so that new ones can be written. To clarify, suppose that the script contains questions numbered sequentially from 1 to 10, and the respondent uses the GoTo button on Q8 to go back to Q5. The interviewer session engine finds the save point for Q4, loads data and temporary variables as they were at that point in the interview, and then executes any statements in the script from there until it reaches Q5. It then displays Q5, deletes any save points for questions after that, and waits for the respondent to answer Q5 again.

Rollbacks do not affect all variables in the same way. As described in the previous paragraph, most variables have their values rolled back (that is, deleted from the cache file) so that values can be reset as the interview continues. These variables, which include all questions and temporary variables, are referred to as transacted variables because they are affected by the rollback. Variables whose values are not affected by a rollback retain their current value and are called untransacted variables. These generally include variables that count the number of times a particular action has taken place, such as Qname.Info.AnswerCount, for instance, that counts the number of times Qname has been asked. Rolling back an interview does not affect the number of times a question has been asked, so the value of this and similar variables is not altered. (In simple terms, a transaction is a work item and, in an interview, everything that takes place between one .Ask() or .Show() statement and another is a single transaction. When an interview is rolled back, the script executed between the .Ask() or .Show() statements if effectively undone or rolled back).

Stopped or timed out interviews can be restarted by entering or selecting the URL for the interview (this is the only way to restart interviews if the browser has been closed since the stop or time-out). In this case, sample management is used to locate the sample record and verify that the interview is in an appropriate state for a restart. The interviewing program then replays the interview from the beginning using the data in the case data database. The replay stops in the following situations:

The interview can then be continued from that point.

In a project that uses quota control, the replay will rerun any quota statements it finds. If the cells that the respondent originally belonged in are now full, the interviewing program will attempt to pend others if this is possible. For example, suppose the respondent originally selected orange juice, milk and water at a quota-controlled question and all three quotas were pended. If the quotas for milk and water are now full, only the quota for orange juice is pended on the restart. Rechecking and repending quotas might or might not affect the rest of the interview. Depending on the instructions in the script, it might terminate immediately if all quotas are full, or a different set of questions might be asked, or it might continue as it did originally. In all cases, any data that becomes obsolete will normally be cleared from the case data.