Sure, one complete explanation coming right up...  but I'm a bit surprised you didn't figure it out yourself... remember, you asked the question...

First, I modified your code so we could...

Don't use sp_Execute.  Just use EXEC...

EXEC (@SQL1+@SQL2+@SQL3....+@SQLn)

... and each of the variables can be VARCHAR(8000).

dba321,

The Inserts that Phil provided are just test code to simulate your much larger table (or result set, whatever)!  You don't need any of those Inserts and you certainly don't...

You certainly don't need a cursor and, if you don't want, you don't need a function... "Trust the force, Luke."

 SELECT CONVERT(VARCHAR(10),SecondsCol/86400)+':'

      + CONVERT(VARCHAR(8),DATEADD(ss,SecondsCol,0),108)

   FROM yourtable

The forces to...

I don't think he meant to be sarcastic... he was just having fun and beat most of us to it.  It's hard to tell in email when someone is joking...

It's customary to share your final solution, if you don't mind.

Jon,

David is correct... since Julian dates recycle every 10 years, should we assume that you will never have a future dated Julian date?

Also, would you rather (recommended) have the date...

David is correct... his link leads to some code I wrote for him to make a "dynamic" cross-tab.  Might have a fat-finger here and there but David wrote and posted...

Jennifer,

Since you want this done in OLTP instead of OLAP, these are more commonly known as "crosstabs" and they run pretty darned fast especially when compared to a cursor and...

With all the good solutions, I feel a little silly posting this but it's nasty fast... and, since a lot of folks keep their Tally (numbers) tables down to something...

Defaults don't work on rows that have already been inserted.  Leaving it up to Developers to remember to include it in code is OK provided the code has to go...

Thanks for the nice things you said, David.  Surprisingly enough, I don't believe you'll find a huge performance gap just because of the use of the Dynamic SQL.  Dynamic SQL...

BWAAAA-HAAAAA-HAAAAAA-HAAAAA!   I just ran the same set of tests on a 4 processor box "real server" with minor traffic for 2,000,000 records using my previous test code and the differences...

Ok, so does that short-term bottleneck stuff explain why my latest test consistently showed that the UDF code was twice as slow as the clear code regardless of the number...

Vladan and Sushila are correct... you may also just try finding the first day of the next month and the looking for anything less than that.