Why this code gives 1 in new query window of SSMS?
select ##ROWCOUNT
SSMS issues several queries after it creates a connection. You can see this using SQL Server Profiler
on my system,
select ##spid;
select SERVERPROPERTY('ProductLevel');
is the last query executed.
When you create a new connection, your SSMS window automatically sets a number of session variables for you.
Sample trace of a new session being created:
select ##spid;
select SERVERPROPERTY('ProductLevel');
As a test you can execute the following statement, and confirm that the result will always be 1.
select ##spid;
select SERVERPROPERTY('ProductLevel');
select ##ROWCOUNT
Related
Hello whenever I select in a new query from the system view sys.dm_tran_session_transactions I get always 0 rows
select * from sys.dm_tran_session_transactions
But people on some other answers use this table.
SQL Server 2005 : map Transaction_ID to ##SPID
Why have I empty this view?
The sys.dm_tran_session_transactions DMV will return sessions with open transactions so it seems there were no such sessions when you ran the query. Start a transaction to see the an example of data returned:
BEGIN TRAN;
SELECT * FROM sys.dm_tran_session_transactions;
ROLLBACK;
I Configured a distribution in SQL Server 2008 using both Wizard and T-SQL but after it when I want to remove it Using Wizard (right clicking on Replication and choosing 'Disable Publishing and Distribution...') or executing following command with and without its parameters:
exec sp_dropdistributor #no_checks = 1 -- no new results with #ignore_distributor = 1
this Error would be presented:
Msq 21122, Level 16, State 1, Procedure sp_dropdistributiondb Line 124
Cannot drop the distribution database 'lobloblob' because it is
currently in use.
I didn't publish any thing, didn't configure any subscription but gave this error
what should I do ?
Try this:
SELECT spid FROM sys.sysprocesses WHERE dbid = db_id('distribution')
Kill the spid and try again. Now it should work.
I used the following scripts:
SELECT spid FROM sys.sysprocesses WHERE dbid = db_id('distribution')
and found that the session_id of current session (which contains the distribution configuration script) doesn't allow to disable distribution so i suggest this script to kill running spid to drop distribution:
use [master]
declare #spid varchar(10)
select #spid=spid from sys.sysprocesses where dbid = DB_ID('distribution')
while ##ROWCOUNTS <> 0
exec ('KILL ' + #spid)
exec sp_dropdistributor #no_checks = 1
My guess would be that the distribution cleanup job is causing the problem. But, to check, prepare to execute the sp_dropdistributor in one window in SSMS and note the session_id of the window. In a second, prepare to run select session_id from sys.dm_os_waiting_tasks where blocked_session_id = <spid from window 1>. Back in window 1, run the proc and then switch back to window 2 and run the select. it'll tell you the session_ids of the sessions blocking the drop of the database.
I have trouble to update some rows in SQL Server (2005 and 2008).
Often, when I try to update one row while having a running query (select * from thistable),
I start the update command and it will fail due to a timeout/lock issue.
It only appears on tables with nvarchar(max)/text columns!
Even if I try to SELECT * FROM thistable WITH(ROWLOCK), I do encounter the same problem.
So my basic question here is:
Can I motivate SQL Server NOT to lock more than the actual row ?
Edit: I first run the SELECT afterwards I try to UPDATE...
There is a great explanation on Locking in SQL-Server on simple talk
Try using:
SELECT * FROM thistable (NOLOCK)
for your select statement.
Then run your update as normal.
I've created an ADO.NET connection manager, and a DataReader source with the following SQL Command:
select
'test' as testcol
INTO
#tmp
select * from #tmp
If I click the refresh button in the DataReader component, I get SqlException "Invalid object name #tmp". The SQL statment itself is clearly valid and executes properly in sql server management studio. I've also tried setting DelayValidation on the connection manager, to no avail.
is the error on the INSERT or the SELECT?
if you are issuing only one command that contains both the INSERT and SELECT, try putting a semicolon before the SELECT.
EDIT after OP comment
encapsulate all the logic within a stored procedure:
CREATE PROCEDURE YourProcedureName
AS
select
'test' as testcol
INTO
#tmp
select * from #tmp
GO
the have your application run this single SQL command:
exec YourProcedureName
EDIT after next OP comment
OP doesn't say which SQL Server version they are using, if 2005 or up, try a CTE:
;with CTEtemp as
(
select
'test' as testcol
)
select * from CTEtemp
Why couldn't this be replaced with a "SELECT 'test' as testcol"? The SSIS query parser may be having trouble with it because there's a temp table involved and it expects a single statement, not an actual SQL script. Or, if what you're sharing above is only an example for illustration, maybe something like this:
SELECT *
FROM (SELECT 'test' AS testcol)
Can you elaborate on what you're trying to accomplish here and, if it is, why the temp table is required?
Use sp_executesql
Your command would become
exec sp_executesql #statement=N'
select
''test'' as testcol
INTO
#tmp
select * from #tmp'
You must use nvarchar string (hence the N), and escape single quotes by doubling them.
I had the same problem as you and this is how I just fixed it.
I am using the Context_Info() variable to keep track of the user that is executing a stored procedure and free-form sql. When troubleshooting issues on this server everyone session comes through. I would like to be able to bring in the value of the context_info() variable and filter based on it.
You can use the UserConfigurable Events along with sp_trace_generateevent (EventId's 82-91) when setting the context_info() to output the values to the trace. Your option is to either do that, or trace the statements setting the context_info(). You won't be able to get the value any other way unless you write a process to dump the output of sys.dm_exec_sessions in a loop while the trace is running:
select session_id, cast(context_info as varchar(128)) as context_info
from sys.dm_exec_sessions
where session_id > 50 -- user sessions
for SQL 2000 you can use sysprocesses:
select spid, cast(context_info as varchar(128)) as context_info
from sysprocesses
where sid > 50 -- user sessions