hm.. reporting database? referential integrity, it may not need. As long as source is valid.

You say rebuilt -- with what method you do use? Drop and recreate...

hmm. Books on SQL for Yoda! Clearly demonstrated, you have, to know much more about SQL than Yoda. Lucky I must have been, then, to even understand...

store data properly, suggests Yoda. Break out these column into two in your database. Combine them for presentation, trivial to do. Separate them for sorting, much harder...

Strong willed, you are. Over 600 years, Yoda has re-written much cursor and dynamic SQL code! Much has Yoda seen, and rarely is dynamic SQL the answer. ...

hmm.

A set-based solution, that is not. One insert required per row. One step it is not! Rather X steps! Requirements of data, depends on this...

hmmm.

Define a standard "base date", you might, then store times only you can. Hiding the date, a formatting issue it becomes, hmm?

The following constraint, consider it you will:

check (check...

hmm.

Patient Yoda must be, to present solution a THIRD time, hmm?

http://www.sqlteam.com/item.asp?ItemID=11499

A true jedi uses the proper tools for the job; dynamic sql leads quickly to the dark...

Joins, conditional they are not!

LEFT OUTER JOINs, you will use. LEFT OUTER JOIN to all tables in questions in 1 single SELECT.

A CASE expression then, you will use,...

Ignored Yoda again, you have.

I can not teach him.

Patience and attention to detail, he has not. Tried what Yoda suggests? No! The path...

too much cursors and dynamic sql, Yoda sees. Leads to the darkside, they do.

Simple problem, it is -- do not process each row. A true jedi will have mastered...

primary key, you have?

Important it is! Without, leads to the dark side.

Yoda will assume it is called "ID" for his example ... more meaningful, Yoda hopes yours is!...

normalize, you must! solve problems, it will!

A true jedi will not store data in columns in that manner.

Consider Yoda's design:

Table: CityPopulation (primary key of City/AgeGroup)

Columns:

City

AgeGroup

PopulationCount

Query it you will!...

Determine server's collation, you must.

sp_helpserver -- run it you will ! results, you shall share.

To determine if a file exists, not a job for a Query!

To return, update or remove data -- a more proper use of T-SQL, hmm?

For what purpose do you desire...

Ignore Yoda's solution to avoid dynamic SQL, do you?

confident you are in your skills. A confidence that can lead to the dark side!

consider your code:

SET @SQL = 'SELECT JOB_id,...