SQL text together with the parameters it refers to. Build one from a string literal, with mkQuery, or from pieces joined with <>; Hmssql.Query shows each way.

The positional parameters are sent as @p1, @p2, ... in the order queryParams lists them, and the named parameters by name. <> appends the text and the parameters of two queries and renumbers the right operand's placeholders past the left operand's positional parameters, so any two queries can be joined. A placeholder that refers to no parameter makes sending the query throw EncodeError.

A query with no parameters is sent as a plain SQL batch, and one with parameters through sp_executesql. fromString (OverloadedStrings) is text as it is, with no parameters. Show is the text as it would be sent, without the parameter values.

The tree of a Query: empty, one piece, or two queries appended.

A query of one piece: fragments whose placeholders are numbered among the positional parameters given, from 1.

A piece of SQL text, or a reference to a positional parameter (1-based).

A parameter: its name ("" for a positional one, otherwise with the leading @) and how to encode its value for a connection.

The fragments of the whole query, placeholders numbered across it. Built strictly, right to left (the whole list is always consumed): lazily, every node and fragment left a thunk, about 190 bytes per fragment.

The parameters of the whole query, in order.

The SQL text as it is sent, with @pN for the placeholders.

A placeholder next to a character that could continue a variable name gets a space between them: "x = " <> param 1 <> "1" is sent as x = @p1 1, not x = @p11 (another parameter), and "N" <> param s as N @p1, not the identifier N@p1.

queryText of the fragments: the static text as it is, each placeholder as @pN with a space on either side where a variable-name character would otherwise run into it, concatenated once.

@p and the number, as queryText writes a placeholder.

Why the query can't be sent, if it can't: a placeholder that refers to a positional parameter it doesn't have.

queryProblem of a query's fragments, given how many positional parameters it has.

A message to send: its packet type and its body, written for the connection's context when it is sent. queryRequest builds one from a Query; startResponse and responseS send one.

A response being read: the reader the query functions share, pulling one step at a time (readStep) until StepEnd. ERROR tokens are withheld (the first kept) and thrown as SqlServerError once the response is complete, so the connection is never left mid-message; a DONE flagged as failed in a response with no ERROR token is thrown as SevereError then.

Not a SQL cursor: it reads one response forwards, once.

What bounds a ResponseReader to one statement of a batch.

The rows at the head of the response, decoded: what one nextStep returns when it finds rows.

What nextStep found next in the response.

One result set of a response: its columns and its rows.

How to decode a response that holds several result sets, one at a time in order, for queryResultSets. Build one from resultSet and skipResultSet with the Applicative or Monad combinators; as a Monad, a later decoder may depend on earlier rows. Statements that produce no result set, such as DECLARE, SET and UPDATE, are skipped over.

(parents, children) <- queryResultSets ((,) <$> resultSet <*> resultSet) conn
  "SELECT id, name FROM dbo.parent; SELECT id, parent_id FROM dbo.child"