I am converting some sql from Oracle to SQL Server 2017.
One of SQL code is having dbms_xplan.Display() inside the script.
I want to know what is the equivalent of dbms_xplan.Display() in SQL Server 2017.
You could use
SHOWPLAN_TEXT:
Causes Microsoft SQL Server not to execute Transact-SQL statements. Instead, SQL Server returns detailed information about how the statements are executed.
SET SHOWPLAN_TEXT ON;
GO
-- your query
GO
SET SHOWPLAN_TEXT OFF;
GO
or if you want to execute query:
STATISTICS PROFILE
Displays the profile information for a statement. STATISTICS PROFILE works for ad hoc queries, views, and stored procedures.
When STATISTICS PROFILE is ON, each executed query returns its regular result set, followed by an additional result set that shows a profile of the query execution.
Last option is to use SHOWPLAN_XML to get nice graphical overview in SSMS.
Related
I had been working with a MySQL database and a JDBC connection. In that case I could easily print a prepared statement using System.out.println(ps);.
But for a SQL Server database it just prints 'SQLServerPreparedStatement' instead of the actual query that will be sent to the server after the parameters have been substituted into the SQL command. How can I accomplish that with SQL Server JDBC?I do not want to achieve that by manual coding like passing all parameters to a function and then bulding the query inside.I want to print it as soon as the query gets executed with effective parameters
You can't. From https://learn.microsoft.com/en-us/sql/connect/jdbc/reference/sqlserverpreparedstatement-class :
"SQLServerPreparedStatement prepares a statement by using the SQL Server sp_prepare stored procedure"
Therefore the final SQL isn't actually held by the JDBC driver.
I am using the SQL Server Profiler to trace the SQL generated from nHibernate in a Windows SmartClient appplication.
The trace of the SQL statement does not show actual data, but rather, looks like this:
exec sp_executesql N'SELECT attachment0_.RecordKey as RecordKey1_, attachment0_.Id as Id1_, attachment0_.Id as Id87_0_, attachment0_.RecordType as RecordType87_0_, attachment0_.RecordKey as RecordKey87_0_, attachment0_.FileName as FileName87_0_, attachment0_.OriginalFileName as Original6_87_0_, attachment0_.DateTimeAttached as DateTime7_87_0_ FROM MyDatabase.dbo.tblAttachment attachment0_ WHERE attachment0_.RecordKey=#p0',N'#p0 int',#p0=262
Is there a way to see the the actual data in the SQL command?
It's just showing the parameterized sql. If you want to log or to show non-parameterized sql I came up with a solution to this here:
Execute NHibernate-generated prepared statements in SQL Server Management Studio
The item of note is the log4net appender that basically translates this in the accepted answer.
I have to run an SQL query that iterates cursor over a larger table (MS SQL Server 2014). It would be rather difficult not to use a cursor for this particular purpose.
The cursor-related code is kept in a stored procedure. R only evaluated EXEC dbo.do_something. EXEC dbo.do_something works as expected when running the code from MS SQL Management Studio. When I run it via RODBC, the query aborts without error message after 30 secs. I guess this is the value of "Connection Timeout".
What options do I have to make the query work with R?
It seems the answer to my particular problem is rather simple: Add SET NOCOUNT ON to the proc definition.
I use Misrosoft SQL Server Management Studio to work with databases. I manually started SP execution on PC One. Is there any way to check if SP is still running or not from a different PC?
The system stored procedure sp_who might be of use: http://technet.microsoft.com/en-us/library/ms174313.aspx
If you know the SPID then you can use
EXEC sp_who <spid>;
Alternatively you can use the login name of the login that executed the command
EXEC sp_who 'george\gvee';
If the cmd column states AWAITING COMMAND then this indicates that that session is not performing a query or other action i.e. it is idle
You can use SQL Server Profiler
http://msdn.microsoft.com/en-us/library/ms187929(v=sql.90).aspx
Use a free tool like Idera SQL Check. Shows graphically a lot of statatiscs about the SQL Server current state.
Ok, i know CONCAT_NULL_YIELDS_NULL will always be set to ON in future versions of SQL (insert MSDN search params(yadda,yadda)) so bear with me.
Boring details: The platform is MSSQL 2000 Enterprise (v8 sp4) AKA Critatious Period Edition.
The following will evaluate to NULL
SELECT 'abc' + NULL;
Understandable. But you can circumvent this with the following:
SET CONCAT_NULL_YIELDS_NULL OFF;
SELECT 'abc' + NULL;
In which case the result is "abc". From here on, future sql statements will allow concatenation with NULL. But is this a 'persistent' runtime setting? Such as, is this setting only applied for my session to the SQL server, or does it apply to statements executed by all users?
As far as i can tell, after setting _YIELDS_NULL to ON, a restart to the MSSQL services will have it default back to OFF (correct me if i'm wrong).
Last thing: I'm not actually planning to put this into practice. A third-party stored procedure failed (looks like they might have updated it, breaking it). Best i can figure is that they implemented it with the assumption that "SET CONCAT_NULL_YIELDS_NULL" was set to ON. And it used to always work.
I'm just looking for a cause: Is there a way to have CONCAT_NULL_YIELDS_NULL set to ON upon SQL server startup?
CONCAT_NULL_YIELDS_NULL can be set:
per connection - when you close connection and open new, it's back to default
per database
open Microsoft SQL Server Management Studio, rightclick your database and select properties. It's in the Miscellaneous section.
or from T-SQL
ALTER DATABASE database_name SET { CONCAT_NULL_YIELDS_NULL OFF }
Note: some clients can issue set concat_null_yields_null on command when opening connection. For example SQL Server Management Studio connecting to SQL 2005 does.
Use SQL Server Profiller to find about your connection.
I do not have SQL 2000 on my notebook to test exactly on that version.
As BOL goes,
If a SET statement is set in a stored
procedure, the value of the SET option
is restored after control is returned
from the stored procedure.
Therefore, the developer has very little to do to ensure correct settings. They could just set them in the beginning of the SP and didn't even have to restore original values afterwards.