Is this statement correct :
In SQL Server 2000 the SQL that checks to see "Is User a DBA" is not valid.
One must use suser_sname instead of suser_name.
See example below:
select 1 where suser_sname()='sa'
go
And if so is there a patch available to correct this ?
Don
"don" <don@.discussions.microsoft.com> wrote in message
news:549733A3-F0B5-4CAD-819A-141BCAF05497@.microsoft.com...
> Is this statement correct :
> In SQL Server 2000 the SQL that checks to see "Is User a DBA" is not
> valid.
> One must use suser_sname instead of suser_name.
> See example below:
> select 1 where suser_sname()='sa'
> go
> And if so is there a patch available to correct this ?
>
Um.
From BOL: SUSER_NAME always returns NULL when used in Microsoft SQL
ServerT 2000. This system built-in function is included only for backward
compatibility. Use SUSER_SNAME instead.
But suser_sname() is not right either. Since many different logins may be
system administrators.
Try
select IS_SRVROLEMEMBER('sysadmin')
David
Showing posts with label dba. Show all posts
Showing posts with label dba. Show all posts
Friday, March 30, 2012
is user dba
Is this statement correct :
In SQL Server 2000 the SQL that checks to see "Is User a DBA" is not valid.
One must use suser_sname instead of suser_name.
See example below:
select 1 where suser_sname()='sa'
go
And if so is there a patch available to correct this ?
Don"don" <don@.discussions.microsoft.com> wrote in message
news:549733A3-F0B5-4CAD-819A-141BCAF05497@.microsoft.com...
> Is this statement correct :
> In SQL Server 2000 the SQL that checks to see "Is User a DBA" is not
> valid.
> One must use suser_sname instead of suser_name.
> See example below:
> select 1 where suser_sname()='sa'
> go
> And if so is there a patch available to correct this ?
>
Um.
From BOL: SUSER_NAME always returns NULL when used in Microsoft SQL
ServerT 2000. This system built-in function is included only for backward
compatibility. Use SUSER_SNAME instead.
But suser_sname() is not right either. Since many different logins may be
system administrators.
Try
select IS_SRVROLEMEMBER('sysadmin')
David
In SQL Server 2000 the SQL that checks to see "Is User a DBA" is not valid.
One must use suser_sname instead of suser_name.
See example below:
select 1 where suser_sname()='sa'
go
And if so is there a patch available to correct this ?
Don"don" <don@.discussions.microsoft.com> wrote in message
news:549733A3-F0B5-4CAD-819A-141BCAF05497@.microsoft.com...
> Is this statement correct :
> In SQL Server 2000 the SQL that checks to see "Is User a DBA" is not
> valid.
> One must use suser_sname instead of suser_name.
> See example below:
> select 1 where suser_sname()='sa'
> go
> And if so is there a patch available to correct this ?
>
Um.
From BOL: SUSER_NAME always returns NULL when used in Microsoft SQL
ServerT 2000. This system built-in function is included only for backward
compatibility. Use SUSER_SNAME instead.
But suser_sname() is not right either. Since many different logins may be
system administrators.
Try
select IS_SRVROLEMEMBER('sysadmin')
David
Monday, February 20, 2012
Is there any advantage for creating a default instance vs. a named
Hello, DBA outthere.
I understand that SQL Server 2000 allows 1 default instance and up to 15
named instances per server. I believe the default instance needs to be
created first.
Is there any reason to have more than 1 instance per server? Does having
more than one instance affect the overall SQL server performance? SQL
2000 server also allows server alias if users to have different server
naming.
I usually create named instance for new installation instead of letting
the SQL setup create the default instance. I had some run-ins with using
named instance. Some not-so-well-prepared application setups looks into
the registry for default instance
(HKL\Software\Microsoft\MSSQLServer\MSSQLServer). If whatever they looks
for is not there, the application will fail. Developers need to take
into account that as SQL Server allows DBA to create either default or
named instance or both.
In any event, give share your thoughts on using default or named instance.
Thanks.
JJ.Hi
Having multiple instances will stretch your resources more. You may want to
create multiple instances if you have a packaged application that require
specific settings or maybe because of issues of security.
I don't think you have to create the default instance first although I have
never tried doing otherwise!
John
"John Joe" <yukondba@.hotmail-lessspam.com> wrote in message
news:%234L5alHiEHA.592@.TK2MSFTNGP11.phx.gbl...
> Hello, DBA outthere.
> I understand that SQL Server 2000 allows 1 default instance and up to 15
> named instances per server. I believe the default instance needs to be
> created first.
> Is there any reason to have more than 1 instance per server? Does having
> more than one instance affect the overall SQL server performance? SQL
> 2000 server also allows server alias if users to have different server
> naming.
> I usually create named instance for new installation instead of letting
> the SQL setup create the default instance. I had some run-ins with using
> named instance. Some not-so-well-prepared application setups looks into
> the registry for default instance
> (HKL\Software\Microsoft\MSSQLServer\MSSQLServer). If whatever they looks
> for is not there, the application will fail. Developers need to take
> into account that as SQL Server allows DBA to create either default or
> named instance or both.
> In any event, give share your thoughts on using default or named instance.
> Thanks.
> JJ.
I understand that SQL Server 2000 allows 1 default instance and up to 15
named instances per server. I believe the default instance needs to be
created first.
Is there any reason to have more than 1 instance per server? Does having
more than one instance affect the overall SQL server performance? SQL
2000 server also allows server alias if users to have different server
naming.
I usually create named instance for new installation instead of letting
the SQL setup create the default instance. I had some run-ins with using
named instance. Some not-so-well-prepared application setups looks into
the registry for default instance
(HKL\Software\Microsoft\MSSQLServer\MSSQLServer). If whatever they looks
for is not there, the application will fail. Developers need to take
into account that as SQL Server allows DBA to create either default or
named instance or both.
In any event, give share your thoughts on using default or named instance.
Thanks.
JJ.Hi
Having multiple instances will stretch your resources more. You may want to
create multiple instances if you have a packaged application that require
specific settings or maybe because of issues of security.
I don't think you have to create the default instance first although I have
never tried doing otherwise!
John
"John Joe" <yukondba@.hotmail-lessspam.com> wrote in message
news:%234L5alHiEHA.592@.TK2MSFTNGP11.phx.gbl...
> Hello, DBA outthere.
> I understand that SQL Server 2000 allows 1 default instance and up to 15
> named instances per server. I believe the default instance needs to be
> created first.
> Is there any reason to have more than 1 instance per server? Does having
> more than one instance affect the overall SQL server performance? SQL
> 2000 server also allows server alias if users to have different server
> naming.
> I usually create named instance for new installation instead of letting
> the SQL setup create the default instance. I had some run-ins with using
> named instance. Some not-so-well-prepared application setups looks into
> the registry for default instance
> (HKL\Software\Microsoft\MSSQLServer\MSSQLServer). If whatever they looks
> for is not there, the application will fail. Developers need to take
> into account that as SQL Server allows DBA to create either default or
> named instance or both.
> In any event, give share your thoughts on using default or named instance.
> Thanks.
> JJ.
Subscribe to:
Posts (Atom)