A member not, of SQL Team yoda is, of this assured you can be...

But worry not -- Yoda is only visiting for a short time! gone soon, he will...

Good advice, Frank provides.

The need for dynamic SQL grows strong, when database is poorly designed! Resist, for this leads to the dark side!

Joins, conditional they should not be. ...

hm.. underused use of the derived table ... perhaps a jedi's most powerful tool, it is! Use it wisely, you must. greatly shorten complicated expressions, it will.

select

...

hmmm... never use proprietary features, hm?

SQL Security, he should not use! system stored procedures -- use them not! If he were programming for windows in C++, MFC classes...

Query analyzer -- use it NOT for reading large text columns! For development and testing, it is. To read 8,000 characters per row -- lots of side scrolling...

Problem lies not in your new expression -- any expression in the SELECT portion, it affects not the number of rows returned.

Your join, the cause of this, it...

hmmm .. advice from Sam, wise indeed.

Normally, a tool of the dark side, Identity is. But use it sometimes you should, guarantees uniqueness it does.

If create invoice...

(sadly) For this one, hopeless it is.  Not for advice, come here has.  To learn something new -- not possible! For him, all is already known.

To Boast of his indestructable...

performance gain, you will not get from that example.  BIT datatypes, index them not.

explicit conversions, yes, is the tool of the jedi.  For performance? minimum gain you may get.  For...

dumb report writer, hm?  Normally presentation layer, you should do this.  Perhaps in this case not possible.

Learn the power of the pivot query, you will!  But this query, not so...

Ask Yoda not "can this be done?" Experiment! It is the tool of the jedi. Try not. Do. Query Analyzer you will open, test view...

Your answer a little you did change, hm?

Yoda's first post in this thread, quietly incorporated the concept, you did? Very wise, indeed.

Though not acknowledging the error of your...

A join you may prefer? Simplier it is, and is the way of the force! Futher more, use not the WHERE clause for Joins! That is the path...

hm.. DROP and then re-CREATE table you must. Or learn the true syntax of ALTER TABLE! Books on-line, the great tomb of jedi knowledge, will lead you there!

however,...

more rows. less columns. more efficient and more scaleable database design. Most importantly, more indexable data! The tools of a true jedi!

Redundant it is not, as it is...