Here's a tip. When dealing with SQL strings, try to minimize the multiline delimiters like quotation marks and concatonators, so that you can easily read the SQL string.
Bad:
string sBrokerSQL = "SELECT MemberId, UserId, PackageConfigId"
+ " FROM Broker"
+ " WHERE"
+ " PushToSystem = 1"
+ " AND UserId IS NOT NULL";
Worse:
StringBuilder sbSql = new StringBuilder();
sbSql.Append("SELECT MemberId, UserId, PackageConfigId");
sbSql.Append(" FROM Broker");
sbSql.Append(" WHERE");
sbSql.Append(" PushToSystem = 1");
sbSql.Append(" AND UserId IS NOT NULL");
Better:
string sBrokersSQL = @"
SELECT MemberId, UserId, PackageConfigId
FROM Broker
WHERE
PushToSystem = 1
AND UserId IS NOT NULL";
With the last sample, you can copy and paste the SQL string right into SQL Server Management Studio (or for SQL 2000 users, into SQL Server Query Analyzer). This formatting is perfectly valid and SQL doesn't care about extra spaces, as long as the SQL itself doesn't have extra spaces in a SQL-quoted value (which should use SqlParameter anyway). If you need to add concatonated bits, you can either use String.Format, or you can break out and restart a "@" sequence again.
string sBrokersSQL = @"
SELECT MemberId, UserId, PackageConfigId
FROM Broker
WHERE
PushToSystem = " + iPush + @"
AND UserId IS NOT NULL";
string sBrokersSQL = String.Format(@"
SELECT MemberId, UserId, PackageConfigId
FROM Broker
WHERE
PushToSystem = {0}
AND UserId IS NOT NULL", iPush);
Likewise, you can follow the same princple when working with dynamically generated SQL in a stored procedure. When concatonating strings to build a SQL query at runtime, the single-quote identifier supports line breaks and doesn't raise any exception as, say, Visual Basic would. It behaves similarly to C# literals having an "@" prefix.