Just observing the obvious here, but about three and a half or so years ago when I heard about C-Omega, which later became LINQ, which then later became a part of C# 3.0, I got the impression that LINQ would perform SQL querying on the fly with integrated SQL-like syntax directly inline with C#, with strong typing and everything. In other words, I thought the language would inherently know ADO.NET/SQL semantics.

It does, but well, no, it doesn't. LINQ isn't an inline SQL translator at all. It is only syntactical sugar for a set of interfaces to a neutral provider to different sources of data. Once the provider is set, LINQ is still not translating SQL inline.

LINQ-to-SQL, LINQ-to-Entities, LINQ-to-NHibernate, LINQ-to-YoMamasDB, all of these use ORM templating and database boilerplating with class-specific generated code to match up the generated SQL.

I'm not against ORM, but it's still too much for smaller (read: tiny) quick-and-dirty hacks. In these cases LINQ (-to-anything) would be overkill galore in the database context. I do say this as a complaint: I still have to use plain old ADO.NET for quick-and-dirty SQL invocation additions, there's no way around it without making it not-so-quick-and-dirty.

Meanwhile, LINQ-to-Objects and LINQ-to-XML are legit. No boilerplating / generated code there. Very sweet.

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.