April 19, 2012 at 2:29 am
itskanchanhere (4/19/2012)
Please do not use print statement in your Sp. If some one trys to execute that sp from any other client apart from SSMS it will fail since Print Statement is specific to SSMS only...
Really? Never had a problem with it. PRINT is not specific to SSMS and it does work with any client using any of standard drivers.
April 19, 2012 at 3:59 am
I used Teradata SQL Assistant client to execute some procedures in SQL Server. Since these had Print statements they failed...Sps without print were successfully executed.. I faced problem only due to Print and Go commands.. Left me baffled for sometime..
April 19, 2012 at 8:05 am
itskanchanhere (4/19/2012)
I used Teradata SQL Assistant client to execute some procedures in SQL Server. Since these had Print statements they failed...Sps without print were successfully executed.. I faced problem only due to Print and Go commands.. Left me baffled for sometime..
thats weird. the GO i can understand since its not really TSQL its the batch separator in SSMS which you can change to what ever you want (Had mine set to BLAH for a while). however the print is a server side command that generates output to sent to the client. my guess is if you would have created the SP out to the server and then called the SP it would work just fine. even if teradata did not display the PRINT returns the SP would have still run. (I Think im stepping way out and might be over the ledge)
For performance Issues see how we like them posted here: How to Post Performance Problems - Gail Shaw[/url]
Need to Split some strings? Jeff Moden's DelimitedSplit8K[/url]
Jeff Moden's Cross tab and Pivots Part 1[/url]
Jeff Moden's Cross tab and Pivots Part 2[/url]
April 19, 2012 at 9:27 am
itskanchanhere (4/19/2012)
I used Teradata SQL Assistant client to execute some procedures in SQL Server. Since these had Print statements they failed...Sps without print were successfully executed.. I faced problem only due to Print and Go commands.. Left me baffled for sometime..
GO might make sense because that is a client-dependent batch separator. However the PRINT issue makes no sense. PRINT statements and informational messages (i.e. RAISERROR with severity of 10 or lower) are both presented on the same TDS output stream, the INFO token stream. If the TeraData client could not handle PRINT output, that means it also could not handle output from a RAISERROR w/ severity <= 10, meaning standard ANSI warnings output from SQL Server would bomb the TeraData client? ...not sure about that product if it cannot handle that correctly.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 19, 2012 at 9:41 am
opc.three (4/19/2012)
itskanchanhere (4/19/2012)
I used Teradata SQL Assistant client to execute some procedures in SQL Server. Since these had Print statements they failed...Sps without print were successfully executed.. I faced problem only due to Print and Go commands.. Left me baffled for sometime..GO might make sense because that is a client-dependent batch separator. However the PRINT issue makes no sense. PRINT statements and informational messages (i.e. RAISERROR with severity of 10 or lower) are both presented on the same TDS output stream, the INFO token stream. If the TeraData client could not handle PRINT output, that means it also could not handle output from a RAISERROR w/ severity <= 10, meaning standard ANSI warnings output from SQL Server would bomb the TeraData client? ...not sure about that product if it cannot handle that correctly.
I suspect these weren't stored procedures (you can't even put a GO in a Stored Procedure). I can understand a generic SQL parser not thinking the code's valid with prints in it when it's submitting it as an ad-hoc batch
April 19, 2012 at 9:46 am
HowardW (4/19/2012)
opc.three (4/19/2012)
itskanchanhere (4/19/2012)
I used Teradata SQL Assistant client to execute some procedures in SQL Server. Since these had Print statements they failed...Sps without print were successfully executed.. I faced problem only due to Print and Go commands.. Left me baffled for sometime..GO might make sense because that is a client-dependent batch separator. However the PRINT issue makes no sense. PRINT statements and informational messages (i.e. RAISERROR with severity of 10 or lower) are both presented on the same TDS output stream, the INFO token stream. If the TeraData client could not handle PRINT output, that means it also could not handle output from a RAISERROR w/ severity <= 10, meaning standard ANSI warnings output from SQL Server would bomb the TeraData client? ...not sure about that product if it cannot handle that correctly.
I suspect these weren't stored procedures (you can't even put a GO in a Stored Procedure). I can understand a generic SQL parser not thinking the code's valid with prints in it when it's submitting it as an ad-hoc batch
Agreed on all accounts. We know GO is not valid SQL, and that PRINT is...I think all of it had to be related to the TeraData client.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 19, 2012 at 5:03 pm
RAISERROR with NOWAIT is also nice because you can build a message inline (using placeholders %d, %s, etc):
RAISERROR (' now is executing step %d...' ,10,1, @step_number) WITH NOWAIT
Add optional parameter @debug to your procedure, and default it to 0:
CREATE PROCEDURE myProc( @param1 int,...., @debug bit=0)
AS
BEGIN
IF @debug=1 RAISERROR ('This is %d...' ,10,1, @param1) WITH NOWAIT
END
GO
If you call that sp with @debug=1 you will see the messages, but rest of application will not see them.
It's just another tool.
Sometimes it is better to use profiler or step-by-step debugger to debug your procedures.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply