CLUSTER NAME

Hi ,
is there any command to display current cluster name through query .
Thanks
ARR
C:\>Cluster /list:[DomainName]
Displays a list of clusters in the computer's domain or a specified domain.
You can use xp_cmdshell to run it in QA.
Ayad Shammout
SR.DBA/Analyst
Caregroup IS
"Aju" <ajuonline@.yahoo.com> wrote in message
news:e5fOYDLGFHA.936@.TK2MSFTNGP12.phx.gbl...
> Hi ,
> is there any command to display current cluster name through query .
> Thanks
> ARR
>

cluseter name (virtual server name)

Hi ,
is there any command to display current cluster name through query .
Thanks
ARR
Aswered in this NG: xp_readreg thread
Regards
Mike
"Aju" wrote:

> Hi ,
> is there any command to display current cluster name through query .
> Thanks
> ARR
>
>

cluseter name (virtual server name)

Hi ,
is there any command to display current cluster name through query .
Thanks
ARRAswered in this NG: xp_readreg thread
Regards
Mike
"Aju" wrote:

> Hi ,
> is there any command to display current cluster name through query .
> Thanks
> ARR
>
>

cluseter name (virtual server name)

Hi ,
is there any command to display current cluster name through query .
Thanks
ARRAswered in this NG: xp_readreg thread
Regards
Mike
"Aju" wrote:
> Hi ,
> is there any command to display current cluster name through query .
> Thanks
> ARR
>
>

CLR function in 2005

If I execute a function in SQL Server 2005 which does a simple query like
SELECT * FROM TableA in an SQL Command object does it require that the
person who executed the CLR stored procedure has select permission on that
object? Or does the CLR proc execute as a DBO? or is it possible to make it
execute as a DBO if not dispite the user who executed it? just security
questions... want to know how to go about writing new procs in the .NET
CLR.. thanks!Same as for TSQL procedures.
The user executing the proc doesn't have to have permissions to the object t
o access, as long as you
don't have a broken ownership chain.
And, you can control user context when creating the proc with the EXECUTE AS
option of the CREATE
PROC command.
However, as soon as you leave the (SQL Server) sandbox, like accessing a fil
e, you need to do
impersonation in your CLR code if you don't want that code to execute with t
he service account that
the SQL Server service is using.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Brian Henry" <nospam@.nospam.com> wrote in message news:%23qwYGyMMGHA.1532@.TK2MSFTNGP12.phx
.gbl...
> If I execute a function in SQL Server 2005 which does a simple query like
SELECT * FROM TableA in
> an SQL Command object does it require that the person who executed the CL
R stored procedure has
> select permission on that object? Or does the CLR proc execute as a DBO? o
r is it possible to make
> it execute as a DBO if not dispite the user who executed it? just security
questions... want to
> know how to go about writing new procs in the .NET CLR.. thanks!
>|||how would you go about doing impersination to make it look like a CLR
account came from a different account?
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:ejliRQNMGHA.2828@.TK2MSFTNGP12.phx.gbl...
> Same as for TSQL procedures.
> The user executing the proc doesn't have to have permissions to the object
> to access, as long as you don't have a broken ownership chain.
> And, you can control user context when creating the proc with the EXECUTE
> AS option of the CREATE PROC command.
> However, as soon as you leave the (SQL Server) sandbox, like accessing a
> file, you need to do impersonation in your CLR code if you don't want that
> code to execute with the service account that the SQL Server service is
> using.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Brian Henry" <nospam@.nospam.com> wrote in message
> news:%23qwYGyMMGHA.1532@.TK2MSFTNGP12.phx.gbl...
>|||> how would you go about doing impersination to make it look like a CLR account came from a

> different account?
Impersonation is only applicable for UNSAFE or EXTERNAL_ACCESS and when you
access things outside
SQL Server. You cannot even access data inside SQL Server while impersonatin
g. The sole purpose is
to access, say, a file using the end users windows account instead of the se
rvice account. More info
at:
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/denet9/html/1495a7af-2248-4cee-afdb-92
69fb3a7774.htm
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Brian Henry" <nospam@.nospam.com> wrote in message news:%2369btZOMGHA.2744@.TK2MSFTNGP10.phx
.gbl...
> how would you go about doing impersination to make it look like a CLR acco
unt came from a
> different account?
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote i
n message
> news:ejliRQNMGHA.2828@.TK2MSFTNGP12.phx.gbl...
>|||"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in news:ejliRQNMGHA.2828@.TK2MSFTNGP12.phx.gbl:

> Same as for TSQL procedures.
> The user executing the proc doesn't have to have permissions to the
> object to access, as long as you don't have a broken ownership chain.
>
Actually that is not completely correct. If the statement in the CLR
proc is a SQL statement, like a select or something like that
(CommandType.Text), then the ownership chain breaks. This is like
executing a dynamic SQL statememnt within a T-SQL proc.
However if the call in the CLR proc is a stored proc call to a T-SQL
proc (CommandType.StoredProcedure) then the ownership chain stays
intact, and you only need execute perms on the CLR proc.
Niels
****************************************
**********
* Niels Berglund
* http://staff.develop.com/nielsb
* nielsb@.no-spam.develop.com
* "A First Look at SQL Server 2005 for Developers"
* http://www.awprofessional.com/title/0321180593
****************************************
**********|||Tack Niels :-)
That was totally unexpected to me. I just had to try it with a CLR object an
d indeed TSQL code
executed inside a CLR proc is handled similar to dynamic SQL in a TSQL proc.
Seems to be yet another
reason to access the data through a TSQL proc inside a CLR proc...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Niels Berglund" <nielsb@.develop.com> wrote in message
news:Xns976D70AB1234Bnielsbdevelopcom@.20
7.46.248.16...
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in news:ejliRQNMGHA.2828@.TK2MSFTNGP12.phx.gbl:
>
> Actually that is not completely correct. If the statement in the CLR
> proc is a SQL statement, like a select or something like that
> (CommandType.Text), then the ownership chain breaks. This is like
> executing a dynamic SQL statememnt within a T-SQL proc.
> However if the call in the CLR proc is a stored proc call to a T-SQL
> proc (CommandType.StoredProcedure) then the ownership chain stays
> intact, and you only need execute perms on the CLR proc.
> Niels
> --
> ****************************************
**********
> * Niels Berglund
> * http://staff.develop.com/nielsb
> * nielsb@.no-spam.develop.com
> * "A First Look at SQL Server 2005 for Developers"
> * http://www.awprofessional.com/title/0321180593
> ****************************************
**********|||"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in news:OZTLgp7MGHA.3460@.TK2MSFTNGP15.phx.gbl:

> Tack Niels :-)
Varsagod :-)!!

> That was totally unexpected to me. I just had to try it with a CLR
> object and indeed TSQL code executed inside a CLR proc is handled
> similar to dynamic SQL in a TSQL proc. Seems to be yet another reason
> to access the data through a TSQL proc inside a CLR proc...
>
Definitely!!!
Niels
****************************************
**********
* Niels Berglund
* http://staff.develop.com/nielsb
* nielsb@.no-spam.develop.com
* "A First Look at SQL Server 2005 for Developers"
* http://www.awprofessional.com/title/0321180593
****************************************
**********

Closed transaction keeps running...awaiting command

I am debugging an app which blocks many processes in a SQL7 server DB.
The app log writes every transaction "open" and "close".
The weird thing is : when the app logfile says the transaction is
dropped (object closed) the db keeps showing the process "running", in
a sleeping mode, with open_tran in 2 or even 3 and in an awaiting
command status.

We are working on NT4.0, SP6a (all fixes up to date, MDAC 2.7SP1) on
IIS side, an equal box for MTS (same patches and updates) and a SQL
Server 7 (on NT4, same fixes ans SPs) database on another box.

Is this normal? Those sleeping processes are blocking other apps and
everything gets slow and messy...the only solution is to kill those
blocking processes.

Thanks![posted and mailed, please reply in news]

Rittercorp (ritter_cl@.yahoo.com) writes:
> I am debugging an app which blocks many processes in a SQL7 server DB.
> The app log writes every transaction "open" and "close".
> The weird thing is : when the app logfile says the transaction is
> dropped (object closed) the db keeps showing the process "running", in
> a sleeping mode, with open_tran in 2 or even 3 and in an awaiting
> command status.
> We are working on NT4.0, SP6a (all fixes up to date, MDAC 2.7SP1) on
> IIS side, an equal box for MTS (same patches and updates) and a SQL
> Server 7 (on NT4, same fixes ans SPs) database on another box.
> Is this normal? Those sleeping processes are blocking other apps and
> everything gets slow and messy...the only solution is to kill those
> blocking processes.

No, this is not normal. Apparently your application has a problem with
transaction scope. The fact that your application log looks good proves
little. The application log may know about transaction it starts, but
what about transactions that starts in SQL code, for instance in
stored procedures?

There are a couple of gotchas. For instance, if you call a stored procedure
and that stored procedure starts a transaction, but the application
cancels the procedure before the execution completed, for instance
because of the dreaded "Timeout expired", the transaction started by
the SP is *not* rolled back. The same is true, if the procedure
starts a transaction, and then is aborted because of a reference to
a non-existing table.

On http://www.sommarskog.se/sqlutil/aba_lockinfo.html I have a
utility that gives yuu a lot of information about locks in the server,
including a list of which are the locked objects. This might be helpful
for you to understand where you are leaking transactions. (Although it
might be messy to find out. Because once a process has missed a
COMMIT or ROLLBACK, it will accumulate locks from all over the place.)

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Clearing Connections

I use the below code to detach my database. Sometimes it fails because there
is an active connection. Is there any command that can overide that
protection or clear the connection without me having to manually detach
inside Ent. Manager?
CODE **********
use master
go
sp_detach_db 'mySQLdatabase'
goHave a look at
http://msdn2.microsoft.com/en-us/library/ms188031(SQL.90).aspx. There's a
section on Obtaining Exclusive Access that tells you how to use ALTER
DATABASE to accomplish what you're trying to do.
Sincerely,
Steve Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
"scott" <sbailey@.mileslumber.com> wrote in message
news:uoQm8bgdGHA.1276@.TK2MSFTNGP03.phx.gbl...
>I use the below code to detach my database. Sometimes it fails because
>there is an active connection. Is there any command that can overide that
>protection or clear the connection without me having to manually detach
>inside Ent. Manager?
> CODE **********
> use master
> go
> sp_detach_db 'mySQLdatabase'
> go
>