October 21, 2011 at 9:28 am
October 21, 2011 at 9:31 am
Any issue with the network?
that would either break the application or slow down the network. With the 2nd option reallllllllllly unlikely unless you're talking about GB of prints per sp.
October 21, 2011 at 9:37 am
The PRINT statement is useful when you are debugging and running from SSMS. I do not see why you would want to have it in a SP that will be called from an application.
But do keep in mind that if you are running this from SSMS and in some kind of loop it could cause memory issues. I have seen it happen in SQL 2000. It started throwing out of memory error in the SQL Server logs.
Just my 2 cents
-Roy
October 21, 2011 at 10:03 am
Hate to say it this way but, it depends. Keep this in mind, every byte of data you send to the client costs time and bandwidth. So yes, it could, whether that impact is large depends on how often you do this and how big that output is as well as how often this sproc is called, so look at it this way "how often" x "how big" x "frequency of calls" = How big it might effect performance.
As a side note, I don't recommend showing the commands in production. For sprocs that are particularly complex or highly dynamic I will sometimes add a DebugFlag that by default is set to NO, when set to yes I will print out tasty tidbits along the way as it is executed. This gives me the best of both worlds, less output in production but output when I need it to debug.
CEWII
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply