In my SQL Server 2014 Management Studio I am facing indentation issue. Like if I create a stored-procedure with proper indentation like tabs, spaces etc.. and if I again check the sp then I see no indentation which I gave while creating the procedures.
Created with proper spacing etc...
What I get after rechecking-
When you execute sp_helptext in SSMS:
exec sp_helptext 'YourSpName'
try setting output type to "Results to Text" instead of "Results to Grid".
You can use the shortcut CTRL+T for this or you can enable it from menu Query/Results To/Results To Grid.
This should preserve indentation.
I am interested in saving the result of a SQL query, like a SELECT statement, as a pipe (|) delimited text file in SSMS.
I can do that using the Export wizard.
However, it seems there's a simpler method by setting a "Custom delimiter" in Tools>Options under Query Results>SQL Server>Results to Text as shown here:
Then, if I specify "Results to Text" or "Results to File", I am supposed to get the pipe delimited result.
This is also outlined here:Obtaining Pipe Delimited Results from SQL Server using SSMS
But, doing this I still get the usual output with either Results to Text or File.
I don't know what I'm missing or doing wrong.
Thanks for your help.
Thanks to #AlexYu, the answer is simply applying the "turning it off and on" trick. Closing and re-opening SSMS is required before the change in this setting takes effect.
Incidentally, disconnecting and re-connecting to the SQL server doesn't work in this case. I have done some rudimentary tests and it seems this also applies to other options here, for example under Query Results>SQL Server>Results to Grid.
I was using Microsoft SQL Server Management Studio v17.9.1, build number 14.0.17289.0.
I think "Query Results" is able to delimit the results by a custom character, only if all the datatype is varchar. I did what you wrote in the description and additionally I casted all the columns to varchar.
SELECT TOP (1000) CAST([COL_A] as varchar) as 'COL_A'
,CAST([COL_B] as varchar) as 'COL_B'
,CAST([COL_C] as varchar) as 'COL_C'
FROM TABLE_NAME;
I have a stored procedure named CreateUpdateNewOrder and i call another SP in it named CreateClinicalDocument Now i want to see what exact values my second SP is getting for execution. I can run a sql profiler tool to see what input values CreateUpdateNewOrder is getting but I can't think of any other way of getting input values for inner SP call other than print them in query. Anyone has better way to do it?
You can run SQL Profiler and select the SPS template instead of the default one.This will show you every statement executed, even if it's inside a stored procedure.To use the SPS template you need to do the following:
File -> New trace
In the dialog that opens go to combo "Use this template" and select TSQL_SPs.
Now continue setting up your profiling session as you would normally.
Once you start the trace you will notice it's much more verbose. It will break down each procedure and will show what's executed line by line.Please let me know if you would need any other details.
It all depends on how you need to access and use the information, but it could be useful to log the values to a table. You could also try Debug in SSMS and set appropriate break points.
If you look at the standard template in profiler you'll see that on the Events Selection tab under the Stored Procedures heading it only includes "RPC:Completed". The T_SQL_SPs template includes "SP:Completed", "SP_Starting" and "SP:StmtStarting". I believe you just need to include those in whatever template you choose.
I'm create a SQL Server Report using Business Intelligence tool (visual studio shell 2005) for SQL Server 2008.
I'm calling a stored procedure with 2 parameters. I've tried - Report-> Report Parameter, Added two parameters name them Days and Count.
In the Data panel "command type:text"
exec dbo.DataReport #Days, #Count
error: Must delcare the scalar variable "#Days"
Does anyone know how do get this too work.
Try changing the command type to Stored Procedure, i'm sure its worked for me in the past
If changing the command type to Stored Procedure like was suggested didn't work, try opening the Dataset dialog box and going to "Parameters" tab. Make sure that both parameters ("#Days" and "#Count") are in the list and that each one has a value.
Does anyone know why.
CREATE PROCEDURE My_Procedure
(#Company varchar(50))
AS
SELECT PRD_DATE
FROM WM_PROPERTY_DATES
WITH (NOLOCK)
WHERE PRD_COMPANY = #Company
GO
Gives me an error message in SQL management studio:
Msg 102, Level 15, State 1, Procedure My_Procedure, Line 1
Incorrect syntax near 'GO'.
Now, this is the last statement of a batch, maybe the last statement should not have a GO ?
If you go to "Save As...", click on the little down-arrow on the Save button and select "Save with Encoding..." then you can set your Line endings to Windows (CR LF). That seems to have resolved the issue for me...
There was a bug released in SQL Server that parses the GO statement incorrectly. I believe it was introduced when you could do GO X, and execute the batch X multiple times.
Sometimes I've had to add a comments section ("--") to force the parser to terminate rather than produce a syntax error. This has been seen when I've had 400,000 lines in a batch of code.
Example:
PRINT "This is a test."
GO --
PRINT "This is not a test."
GO 5 --
The sql you currently have in the question will work properly. The unformatted sql you had before Kev edited the post won't. The reason is that you had the GO on the same line as the sql. It needs to be on a separate line.
If you copy-paste text from text editor with Unix/Mac EOLs (e.g. Notepad++ supports this) the GO is interpreted as being on the same line as the last TSQL statement (yet on the screen you can see newlines normally). Converting EOLs to Windows (CRLF) in the text editor fixed the problem. Very tricky though.
Error for this sql
ALTER PROCEDURE My_Procedure
(#Company varchar(50))
AS
SELECT PRD_DATE
FROM WM_PROPERTY_DATES
WITH (NOLOCK)
WHERE PRD_COMPANY = #Company GO
is
Msg 102, Level 15, State 1, Procedure My_Procedure, Line 7
Incorrect syntax near 'GO'.
note the Line 7, original question has Line 1.
If I put the GO on its own line SQL works fine.
Given that your error message says Line 1, it would appear that for some reason there isnt a correct CR/LF happening in your sql.
You can certainly have GO at the end of your batch. I see nothing wrong with this code per se. Put a semicolon after #Company.
I tried this SQL on my 2008 server by creating a table WM_PROPERTY_DATES and adding 2 columns, PRD_DATE and PRD_COMPANY.
Work just fine and creates the proc. Maybe you can try putting your code in a BEGIN...END block and see if the issue persists.
Raj
You said
Now, this is the last statement of a
batch, maybe the last statement should
not have a GO ?
This implies that these lines are all part of the same batch submitted to SQL. The thing is, a CREATE PROCEDURE (or CREATE FUNCTION or CREATE VIEW) statement must be the first statement in the batch. So, put a "GO" line in front of that CREATE statement, and see what happens.
Philip
In my case I had copied part of the code from a webpage and it seems that saved the page with different encoding, I tried SaveAs from SMS with different encoding, but didn't work.
To fix my issue I copy the code into NodePad, then save it in ANSI format and re-open the query
No serious company could possibly pretend to add GO after each statement. Perhaps after each batch.
GO is not a Transact-SQL statement. Is a delimiter understood by tools like ISQLW (aka. Query analizer), osql, sqlcmd and SSMS (Management Studio). These tools split the SQL file into batches, delimited by GO (or whatever is the 'batch delimiter' set, to to be accurate, but is usually GO) and then send to the server one batch at a time. The server never sees the GO, and if it would see it then it would report an error 102, incorrect syntax, as you already seen.