If there's an output parameter, RequiresResultPropagation is true so we go into the wrong flow for the result set.
We could split this into RequiresResultColumnPropagation/RequiresOutputParameterPropagation. However, there's another bug with TPH with sibling result columns: we don't need to propagate anything, but the sproc really does return a row (and not just rows affected). So we need to go into ConsumeResultSetWithPropagation, and not into ConsumeResultSetWithoutPropagation.
To fix this, rather than using RequiresResultPropagation to determine how we consume the result set, we'll add a bit to ResultSetMapping which tells us whether the result set consists exclusively of a rows affected value.
In addition, we'll add validation so that if a sproc has any result columns, it cannot also have a rows affected value anywhere, in any form; once there are result columns, the existence of a result row is sufficient to know whether a concurrency failure occured or not, and the rows affected value is ignored anyway.
Note that we'll use ColumnModification.IsRead to indicate whether a value needs to be read and propagated; in other words, for rows affected and sibling TPH properties IsRead will be false. This distinction is only important for sprocs, since for regular SQL, if we don't want to propagate something, we also don't generate SQL to return it.
If there's an output parameter, RequiresResultPropagation is true so we go into the wrong flow for the result set.
We could split this into RequiresResultColumnPropagation/RequiresOutputParameterPropagation. However, there's another bug with TPH with sibling result columns: we don't need to propagate anything, but the sproc really does return a row (and not just rows affected). So we need to go into ConsumeResultSetWithPropagation, and not into ConsumeResultSetWithoutPropagation.
To fix this, rather than using RequiresResultPropagation to determine how we consume the result set, we'll add a bit to ResultSetMapping which tells us whether the result set consists exclusively of a rows affected value.
In addition, we'll add validation so that if a sproc has any result columns, it cannot also have a rows affected value anywhere, in any form; once there are result columns, the existence of a result row is sufficient to know whether a concurrency failure occured or not, and the rows affected value is ignored anyway.
Note that we'll use ColumnModification.IsRead to indicate whether a value needs to be read and propagated; in other words, for rows affected and sibling TPH properties IsRead will be false. This distinction is only important for sprocs, since for regular SQL, if we don't want to propagate something, we also don't generate SQL to return it.