Felipe,
Do you want to manage long SQL statements or do you want to manage long
string manipulation. I see them as two largely different problems.
Personally anything other then a Component or Stored Procedures for Long SQL
statements is not good enough! As you are finding you run into "problems"
trying to manipulate the SQL statement as a string.
Also if you happen to be concatenation in any parameters (instead of using
parameter markers) then you are opening yourself for even more pain, as you
will need to manually "quote" the parameters, which is a pain, why reinvent
the wheel, using parameter markers & parameter object will properly handle
all quoting for you, also you avoid "injection attacks" especially on web
pages where you allow an id to be requested (maybe indirectly via
QueryString) and simply concatenate this QueryString value into the SQL,
what happens when someone modifies the QueryString such that it includes
other SQL statements? Remember SQL Server supports multiple statements
separated via a semicolon.
So what I want is a way to manage long string manipulation.
I still question if you are wanting long string manipulation or simply
building long string constants.
If you are truly manipulating long strings, consider using a StringBuilder.
If performance & GC profiling suggest it is a performance issue.
If your (non SQL) string is a constant I would stick with what you had
originally had, as the constant will be created at compile time, with no
runtime performance issues.
If for some reason you don't want to use Visual Designers for managing your
SQL statements I've seen others suggest storing the SQL statements in an
external file. I would use either an external text file or an XML file, if I
used an XML file I would consider using an embedded Resource file (.resx) to
avoid the file itself from being modified.
However I would hope once you fully understand what the Component is buying
you will change your opinion on using Component...
Hope this helps
Jay