The UNICOM Intelligence Interviewer services depend on continuous access to SQL Server. The access requirement can be a problem when SQL clusters are used because there is a short outage between the primary SQL Server failure and the secondary server takeover. To make Interviewer Server as reliable as possible in these situations, the following procedures are implemented when there is a failure to access the necessary databases.

Reconnections to the database are attempted a single time. If the connection attempt fails, then the interview also fails but the interview engine remains active. Interviews start successfully after the database connection returns. Interviews will fail during a network outage, but then start after the network outage is over.

At the start or end of an interview, several database tables are accessed.

The table contains project properties, including sample management properties, and is accessed when one of the components that changes project properties indicates that an update has occurred. The table is also accessed when the services start. DPM is relatively resilient to database failures and network outages. Nevertheless, Interviewer Server a reconnection attempt occurs if the initial connection attempt fails.

The database contains several tables that are used by the RDB DSC to store data for each respondent. Interviewer Server keeps one connection to this database open on each Interview computer to ensure that interviews start quickly. The Project objects cache holds a connection to this database in a way that is easily accessible. If the open connection fails at the start of an interview, data is written to the cache subscription file in the interview cache folder. Case data from the cache subscription file is later transferred to the case database (when the database is available).

The table contains sample records that are typically accessed during AuthenticateSampleRec and ReturnSampleRec. When an access to the table fails, a reconnection attempt occurs, and then fails. This scenario typically results either in a failure to authenticate (meaning that the respondent sees an Authentication Retry page), or in a failure to return (meaning that the record is left in an active state). After the network outage is over, authentication or return succeeds, even though the records left in the active state must be recovered.

When a network failure occurs, after an interview is started, the interview continues. SQL statements fail but are written to the cache subscription file in the interview cache folder. No action is required if the database is unavailable only during interviews.

When a network failure occurs during activation, the activation fails because the project properties cannot be updated in DPM. After the network outage is over, activation succeeds.