The PRINT statement in SQL Server's T-SQL language is useful but one of the biggest restrictions with it is the size of the strings that it can print. Where this becomes a big issue is if you are needing to create dynamic SQL statements (which you obviously need to be careful of in the first place) or scripting database objects, and the statements need to be either executed or printed.
In our free SDU Tools for developers and DBAs, we added a procedure ExecuteOrPrint to help with this. You can pass it a large string (nvarchar(max) typically) and tell it to either execute the value, or if you are using it for scripting or debugging, to print the value.
The default action is to print the value.
We designed it to help with both scenarios in the same code. For example, in scripting, you might want batch separators (ie: GO) but when executing, you don't want to send those to the server, you want to carve up the script and send it in batches, based upon the separator. It can also add carriage returns and line feeds as required.
The parameters are as follows:
@StringToExecuteOrPrint nvarchar(max) -> String containing SQL commands
@PrintOnly bit = 1 -> If set to 1 commands are printed only not executed
@NumberOfCrLfBeforeGO int = 0 -> Number of carriage return linefeeds added before the batch separator (normally GO)
@IncludeGO bit = 0 -> If 1 the batch separator (normally GO) will be added
@NumberOfCrLfAfterGO int = 0 -> Number of carriage return linefeeds added after the batch separator (normally GO)
@BatchSeparator nvarchar(20) = N'GO' -> Batch separator to use (defaults to GO)
You can also see it in action here:
To become an SDU Insider and to get our free tools and eBooks, please just visit here: