3.1.5 Message Processing Events and Sequencing Rules

Whenever an error occurs during processing of a message sent by a protocol client, the protocol server MUST report an error back to the protocol client as follows:

1. Stop processing the message sent by the protocol client.

2. Respond with the message header (only) of the message sent by the protocol client, keeping _msg field intact.

3. Set the _status field to the error code value.

When a message arrives, the protocol server MUST check the field value to see if it is a known type (see section 2.2.2). If the type is not known, it MUST report a STATUS_INVALID_PARAMETER (0xC000000D) error. The protocol server MUST then validate the _ulChecksum field value if the message type is one of the following:

• CPMConnectIn (0x000000C8)

• CPMCreateQueryIn (0x000000CA)

• CPMSetBindingsIn (0x000000D0)

• CPMGetRowsIn (0x000000CC)

• CPMFetchValueIn (0x000000E4)

The protocol server MUST validate that the _ulChecksum field was calculated as specified in section 3.2.4. If the _ulChecksum value is invalid, the protocol server MUST report a STATUS_INVALID_PARAMETER (0xC000000D) error.

Next, the protocol server checks which state is it in. If its state is "not initialized", the protocol server MUST report a CI_E_NOT_INITIALIZED (0x8004180B) error. If the state is "shutting down", the protocol server MUST report a CI_E_SHUTDOWN (0x80041812) error.

After a header has been determined to be valid and the protocol server to be in "running" state, further message-specific processing MUST be done as specified in the following subsections.

Some messages are only valid after a previous message has been sent. An identifier or handle from the earlier message can be required as input to the later message. These requirements are detailed in the following sections. In the following table that summarizes the relationship between messages, an X mark means that the protocol client MUST NOT send the message specified in the row before it received the response specified in the column.