A funny thing happened the other day. I was running 64-bit Dev edition on my 4Gb Vista 64-bit notebook. SQL Server was set to 1Gb RAM and I was running 10 scripts each continually inserting a new randomly generated person into a table. The goal was to generate 500 million rows. Meanwhile, I was checking email, doing some browsing, doing some writing – normal things. I couldn’t even feel a difference with SQL Server running smoothly in the background.  I was feeling rather smug about my 64-bit machine.

A couple hours later.. 

the machine started slowing down just a wee bit, and watching the Vista widget reporting memory the used memory started crawling upward – 75%, 83%, eventually it stopped crawling at 97% memory used. At this point the machine was taking minutes to respond to mouse clicks. I was up to about 300 million rows in the Person table when I stopped the scripts.

I checked SQL Server memory and it was still right at 1Gb target and 1Gb used. What was going on? Looking at Task Manager, SQLWB.exe was at 1.7Gb. What?!?! How did that happen?

.

.

.

.

.

Baffled, I mentioned it to Sue Hoegemeier, another Colorado based SQL Server MVP who in a rather scary way can quote obscure knowledgebase articles. She laughed and with a wry grin said “Set NoCount On.” Of course I do that religiously in every proc “AS SET NoCount ON …”. But in these quick scripts I had overlooked the nocount. SQLWB (Management Studio was originally going to be named SQL WorkBench hence the name) was filling up with millions and millions of "1 row affected" messages.