Aw, what the heck... do it all in SQL... pick your poison...

 SELECT STUFF(RIGHT(CONVERT(CHAR(11),MonthDate,113),8),4,3,'-') AS [Month],

        COUNT(*) AS [Number of Requests Completed]

   FROM #MonthGroup

  GROUP BY STUFF(RIGHT(CONVERT(CHAR(11),MonthDate,113),8),4,3,'-')

Shoot... only 4 gig?  We set our temp db to 12 gig... ON PURPOSE!  Got resources?  Use 'em.

2nd post in as many days for this same thing... you guys got a little homework from the same professor?

Try this... most of it is test setup code... AND, it's...

Very clever. 

Slight mod for you...Take out the initial variable load and you won't get the leading (or trailing) commas... change the two variable lengths also gets rid of the...

Sorry... wasn't talking about the concept of BI... I was talking about the expensive products people buy to do BI.... we made our own because nobody seemed to be doing...

Try this from Query Analyzer...

EXEC Master.dbo.xp_DirTree 'C:\',0,1

Then, read up on the dangers of using undocumented features.  Also keep in mind that Microsoft can also change or eliminate API's just as...

SQLBill,

I'm amazed at how many folks don't know about the STUFF function... you beat me to it...

That's why instant messaging works great. It's like a conversation between two people.

I just can't bring myself...

Hi Mike,

Thanks for the feedback.... using the data in my test table, the function you built runs out of gas on the small numbers no matter how many decimal places...

Khanh,

If you came up with a solution different than any of those posted, would you share it with us?  Thanks...

The easy way to figure this out (find the problem) is to just type out the SELECT as you normally would...

Then, everywhere you see a single quote, add another single quote...

Nope... not a problem... I knew it wasn't personal... you're right about the daily date questions and the "mistrakes" folks make doing things on a global basis.  Shoot, I still have guys...

Careful... won't get down into the decimal places...

TestValue                                                                        

---------------------------------------- ----------------------------------------

1245600085.0000000000000000000           1246000000.00000000

124560008.5000000000000000000            124600000.00000000

12456000.8500000000000000000             12460000.00000000

1245600.0850000000000000000              1246000.00000000

124560.0085000000000000000               124600.00000000

12456.0008500000000000000                12460.00000000

1245.6000850000000000000                 1246.00000000

124.5600085000000000000                  124.60000000

12.4560008500000000000                   12.46000000

1.2456000850000000000                    1.24600000

(11 row(s) affected)

Server: Msg 8134, Level 16, State 1, Line...

You bet... and to confirm, yes, CHAR(9) is the tab character.  You might be able to simplify things if you used the tabl character as a delimiter in the import...

Yep... that too.  For the record, there is no TRIM function in SQL Server 7 or 2000... just LTRIM and RTRIM.  Dunno about 2005.