permissions to run start and stop jobs

Using SS2000 SP4. I have a user who is able to start and stop jobs. The user
only has db_owner permissions in a few databases. Should someone who is in
the db_owner role be able to start and stop jobs or run dts packages?
The user didn't used to be able to even see the jobs so I'm not sure what
changed.
--
Dan D.Normally, a user needs to be a member of sysadmins SQL
server role to start and stop any and all jobs. If not a
sysadmin, the user can only start and stop jobs that they
own.
Who owns the jobs? If the user owns the jobs, they can start
and stop the job. Also, did you verify that the user is
really using their login? Maybe they have EM registered with
a sysadmin login - that wouldn't be too hard to see in
sysprocesses when the user is connected - just check with
the hostname, program_name, loginame.
Another thing to check would be if the user is actually in
the sysamin server role inherited through Windows group
membership. If you left the BUILTIN\Administrators login in
SQL Server set to the default, was the user added to the
local administrators group on the server? That would be one
way...other ways would depend on what Windows groups are in
the syadmin SQL Server role. Then check to see if that user
is a member of any Windows group.
-Sue
On Thu, 7 Sep 2006 07:42:02 -0700, Dan D.
<DanD@.discussions.microsoft.com> wrote:

>Using SS2000 SP4. I have a user who is able to start and stop jobs. The use
r
>only has db_owner permissions in a few databases. Should someone who is in
>the db_owner role be able to start and stop jobs or run dts packages?
>The user didn't used to be able to even see the jobs so I'm not sure what
>changed.|||BUILTIN\Administrators doesn't exist. Domain\Administrator and Administrator
exist but they do not have any sysadmin type permissions.
I have another domain user setup and is the login for the SQLServer Agent
service and that user owns all jobs.
We checked the administrator groups for the domain and locally and the users
are not in there or part of a group that is in the admin group.
How would the user show up in sysprocesses? I see several entries for 'sa'
but they're all in the master database and background except for one that ha
s
'no database context' and is sleeping. Same for 'system' user.
There is an 'NT Authority\System' login that has sysadmin permisions. Is
there any way a user could use that login?
Thanks for so many choices.
--
Dan D.
"Sue Hoegemeier" wrote:

> Normally, a user needs to be a member of sysadmins SQL
> server role to start and stop any and all jobs. If not a
> sysadmin, the user can only start and stop jobs that they
> own.
> Who owns the jobs? If the user owns the jobs, they can start
> and stop the job. Also, did you verify that the user is
> really using their login? Maybe they have EM registered with
> a sysadmin login - that wouldn't be too hard to see in
> sysprocesses when the user is connected - just check with
> the hostname, program_name, loginame.
> Another thing to check would be if the user is actually in
> the sysamin server role inherited through Windows group
> membership. If you left the BUILTIN\Administrators login in
> SQL Server set to the default, was the user added to the
> local administrators group on the server? That would be one
> way...other ways would depend on what Windows groups are in
> the syadmin SQL Server role. Then check to see if that user
> is a member of any Windows group.
> -Sue
> On Thu, 7 Sep 2006 07:42:02 -0700, Dan D.
> <DanD@.discussions.microsoft.com> wrote:
>
>|||Well...the user needs to be connected to see them in
sysprocesses. You'd want to know what PC they use - that
would show up in hostname.
But probably stepping back a bit is a good idea. All the
same things I posted apply but how do you know the user is
executing jobs? Do you know how the user is executing jobs -
such as does the user connect from Enterprise Manager and
just start and stop jobs at will?
-Sue
On Thu, 7 Sep 2006 09:14:02 -0700, Dan D.
<DanD@.discussions.microsoft.com> wrote:

>BUILTIN\Administrators doesn't exist. Domain\Administrator and Administrato
r
>exist but they do not have any sysadmin type permissions.
>I have another domain user setup and is the login for the SQLServer Agent
>service and that user owns all jobs.
>We checked the administrator groups for the domain and locally and the user
s
>are not in there or part of a group that is in the admin group.
>How would the user show up in sysprocesses? I see several entries for 'sa'
>but they're all in the master database and background except for one that h
as
>'no database context' and is sleeping. Same for 'system' user.
>There is an 'NT Authority\System' login that has sysadmin permisions. Is
>there any way a user could use that login?
>Thanks for so many choices.|||The user said that he could start a job. And I know that someone stopped a
job the other day. Also, the user said that he could backup the database.
I'll keep an eye on the hostname and see if anyone is logged on as 'sa'. I
also might change the 'sa' password on this server.
Thanks for your suggestions.
--
Dan D.
"Sue Hoegemeier" wrote:

> Well...the user needs to be connected to see them in
> sysprocesses. You'd want to know what PC they use - that
> would show up in hostname.
> But probably stepping back a bit is a good idea. All the
> same things I posted apply but how do you know the user is
> executing jobs? Do you know how the user is executing jobs -
> such as does the user connect from Enterprise Manager and
> just start and stop jobs at will?
> -Sue
> On Thu, 7 Sep 2006 09:14:02 -0700, Dan D.
> <DanD@.discussions.microsoft.com> wrote:
>
>|||Yup...changing he password in case they got ahold of that is
a good idea. You may also want to run a trace when the user
is at work. Had to do those before. You tend to find other
more interesting activities they do. Often has some
entertainment value if nothing else.
-Sue
On Fri, 8 Sep 2006 11:22:01 -0700, Dan D.
<DanD@.discussions.microsoft.com> wrote:

>The user said that he could start a job. And I know that someone stopped a
>job the other day. Also, the user said that he could backup the database.
>I'll keep an eye on the hostname and see if anyone is logged on as 'sa'. I
>also might change the 'sa' password on this server.
>Thanks for your suggestions.|||A little extra entertainment is good. Thanks.
--
Dan D.
"Sue Hoegemeier" wrote:

> Yup...changing he password in case they got ahold of that is
> a good idea. You may also want to run a trace when the user
> is at work. Had to do those before. You tend to find other
> more interesting activities they do. Often has some
> entertainment value if nothing else.
> -Sue
> On Fri, 8 Sep 2006 11:22:01 -0700, Dan D.
> <DanD@.discussions.microsoft.com> wrote:
>
>sql

permissions to run start and stop jobs

Using SS2000 SP4. I have a user who is able to start and stop jobs. The user
only has db_owner permissions in a few databases. Should someone who is in
the db_owner role be able to start and stop jobs or run dts packages?
The user didn't used to be able to even see the jobs so I'm not sure what
changed.
--
Dan D.Normally, a user needs to be a member of sysadmins SQL
server role to start and stop any and all jobs. If not a
sysadmin, the user can only start and stop jobs that they
own.
Who owns the jobs? If the user owns the jobs, they can start
and stop the job. Also, did you verify that the user is
really using their login? Maybe they have EM registered with
a sysadmin login - that wouldn't be too hard to see in
sysprocesses when the user is connected - just check with
the hostname, program_name, loginame.
Another thing to check would be if the user is actually in
the sysamin server role inherited through Windows group
membership. If you left the BUILTIN\Administrators login in
SQL Server set to the default, was the user added to the
local administrators group on the server? That would be one
way...other ways would depend on what Windows groups are in
the syadmin SQL Server role. Then check to see if that user
is a member of any Windows group.
-Sue
On Thu, 7 Sep 2006 07:42:02 -0700, Dan D.
<DanD@.discussions.microsoft.com> wrote:
>Using SS2000 SP4. I have a user who is able to start and stop jobs. The user
>only has db_owner permissions in a few databases. Should someone who is in
>the db_owner role be able to start and stop jobs or run dts packages?
>The user didn't used to be able to even see the jobs so I'm not sure what
>changed.|||BUILTIN\Administrators doesn't exist. Domain\Administrator and Administrator
exist but they do not have any sysadmin type permissions.
I have another domain user setup and is the login for the SQLServer Agent
service and that user owns all jobs.
We checked the administrator groups for the domain and locally and the users
are not in there or part of a group that is in the admin group.
How would the user show up in sysprocesses? I see several entries for 'sa'
but they're all in the master database and background except for one that has
'no database context' and is sleeping. Same for 'system' user.
There is an 'NT Authority\System' login that has sysadmin permisions. Is
there any way a user could use that login?
Thanks for so many choices.:)
--
Dan D.
"Sue Hoegemeier" wrote:
> Normally, a user needs to be a member of sysadmins SQL
> server role to start and stop any and all jobs. If not a
> sysadmin, the user can only start and stop jobs that they
> own.
> Who owns the jobs? If the user owns the jobs, they can start
> and stop the job. Also, did you verify that the user is
> really using their login? Maybe they have EM registered with
> a sysadmin login - that wouldn't be too hard to see in
> sysprocesses when the user is connected - just check with
> the hostname, program_name, loginame.
> Another thing to check would be if the user is actually in
> the sysamin server role inherited through Windows group
> membership. If you left the BUILTIN\Administrators login in
> SQL Server set to the default, was the user added to the
> local administrators group on the server? That would be one
> way...other ways would depend on what Windows groups are in
> the syadmin SQL Server role. Then check to see if that user
> is a member of any Windows group.
> -Sue
> On Thu, 7 Sep 2006 07:42:02 -0700, Dan D.
> <DanD@.discussions.microsoft.com> wrote:
> >Using SS2000 SP4. I have a user who is able to start and stop jobs. The user
> >only has db_owner permissions in a few databases. Should someone who is in
> >the db_owner role be able to start and stop jobs or run dts packages?
> >
> >The user didn't used to be able to even see the jobs so I'm not sure what
> >changed.
>|||Well...the user needs to be connected to see them in
sysprocesses. You'd want to know what PC they use - that
would show up in hostname.
But probably stepping back a bit is a good idea. All the
same things I posted apply but how do you know the user is
executing jobs? Do you know how the user is executing jobs -
such as does the user connect from Enterprise Manager and
just start and stop jobs at will?
-Sue
On Thu, 7 Sep 2006 09:14:02 -0700, Dan D.
<DanD@.discussions.microsoft.com> wrote:
>BUILTIN\Administrators doesn't exist. Domain\Administrator and Administrator
>exist but they do not have any sysadmin type permissions.
>I have another domain user setup and is the login for the SQLServer Agent
>service and that user owns all jobs.
>We checked the administrator groups for the domain and locally and the users
>are not in there or part of a group that is in the admin group.
>How would the user show up in sysprocesses? I see several entries for 'sa'
>but they're all in the master database and background except for one that has
>'no database context' and is sleeping. Same for 'system' user.
>There is an 'NT Authority\System' login that has sysadmin permisions. Is
>there any way a user could use that login?
>Thanks for so many choices.:)|||The user said that he could start a job. And I know that someone stopped a
job the other day. Also, the user said that he could backup the database.
I'll keep an eye on the hostname and see if anyone is logged on as 'sa'. I
also might change the 'sa' password on this server.
Thanks for your suggestions.
--
Dan D.
"Sue Hoegemeier" wrote:
> Well...the user needs to be connected to see them in
> sysprocesses. You'd want to know what PC they use - that
> would show up in hostname.
> But probably stepping back a bit is a good idea. All the
> same things I posted apply but how do you know the user is
> executing jobs? Do you know how the user is executing jobs -
> such as does the user connect from Enterprise Manager and
> just start and stop jobs at will?
> -Sue
> On Thu, 7 Sep 2006 09:14:02 -0700, Dan D.
> <DanD@.discussions.microsoft.com> wrote:
> >BUILTIN\Administrators doesn't exist. Domain\Administrator and Administrator
> >exist but they do not have any sysadmin type permissions.
> >
> >I have another domain user setup and is the login for the SQLServer Agent
> >service and that user owns all jobs.
> >
> >We checked the administrator groups for the domain and locally and the users
> >are not in there or part of a group that is in the admin group.
> >
> >How would the user show up in sysprocesses? I see several entries for 'sa'
> >but they're all in the master database and background except for one that has
> >'no database context' and is sleeping. Same for 'system' user.
> >
> >There is an 'NT Authority\System' login that has sysadmin permisions. Is
> >there any way a user could use that login?
> >
> >Thanks for so many choices.:)
>|||Yup...changing he password in case they got ahold of that is
a good idea. You may also want to run a trace when the user
is at work. Had to do those before. You tend to find other
more interesting activities they do. Often has some
entertainment value if nothing else.
-Sue
On Fri, 8 Sep 2006 11:22:01 -0700, Dan D.
<DanD@.discussions.microsoft.com> wrote:
>The user said that he could start a job. And I know that someone stopped a
>job the other day. Also, the user said that he could backup the database.
>I'll keep an eye on the hostname and see if anyone is logged on as 'sa'. I
>also might change the 'sa' password on this server.
>Thanks for your suggestions.|||A little extra entertainment is good. Thanks.
--
Dan D.
"Sue Hoegemeier" wrote:
> Yup...changing he password in case they got ahold of that is
> a good idea. You may also want to run a trace when the user
> is at work. Had to do those before. You tend to find other
> more interesting activities they do. Often has some
> entertainment value if nothing else.
> -Sue
> On Fri, 8 Sep 2006 11:22:01 -0700, Dan D.
> <DanD@.discussions.microsoft.com> wrote:
> >The user said that he could start a job. And I know that someone stopped a
> >job the other day. Also, the user said that he could backup the database.
> >
> >I'll keep an eye on the hostname and see if anyone is logged on as 'sa'. I
> >also might change the 'sa' password on this server.
> >
> >Thanks for your suggestions.
>

permissions needed for trigger

Using SS2000 SP4. We're using a .NET application. What permissions should be
needed for a user to fire a trigger. Ideally, I wanted the user (userWill) t
o
only have execute permissions on the stored procedures and select permission
s
on the views. But all views, stored procedures and triggers are qualified
with "dbo".
But when I try to update a table and the trigger fires I get these errors:
Server: Msg 229, Level 14, State 5, Line 1
SELECT permission denied on object 'tblFranchiseContacts', database
'SMCLMS_Dan', owner 'dbo'.
Server: Msg 229, Level 14, State 1, Line 1
UPDATE permission denied on object 'tblFranchiseContacts', database
'SMCLMS_Dan', owner 'dbo'.
If I run exec sp_helpdb 'smclms_dan' I get archer\dbober as the owner.
How do I get around this?
Thanks,
--
Dan D.Hi,
You do not need to specify permissions on triggers. Triggers are executed on
UPDATE, INSERT and DELETE statements. So, in order to execute these triggers
users need to have these permissions on the tables holding the triggers non
on the trigger themselves.
Ben Nevarez, MCDBA, OCP
Database Administrator
"Dan D." wrote:

> Using SS2000 SP4. We're using a .NET application. What permissions should
be
> needed for a user to fire a trigger. Ideally, I wanted the user (userWill)
to
> only have execute permissions on the stored procedures and select permissi
ons
> on the views. But all views, stored procedures and triggers are qualified
> with "dbo".
> But when I try to update a table and the trigger fires I get these errors:
> Server: Msg 229, Level 14, State 5, Line 1
> SELECT permission denied on object 'tblFranchiseContacts', database
> 'SMCLMS_Dan', owner 'dbo'.
> Server: Msg 229, Level 14, State 1, Line 1
> UPDATE permission denied on object 'tblFranchiseContacts', database
> 'SMCLMS_Dan', owner 'dbo'.
> If I run exec sp_helpdb 'smclms_dan' I get archer\dbober as the owner.
> How do I get around this?
> Thanks,
> --
> Dan D.|||Dan,
If the owner of the table and the owner of the sp or view are the same then
the end-user accessing the sp or view does not need to have permissions on
the underlying tables. This provides a security abstraction layer to the
underlying objects. However, if the owners are not the same then you have a
broken ownership chain in which case permissions are required. There are no
execute trigger permissions.
For more information on this, see the security chapter I wrote a while back
in the SQL Server 2000 Operations Guide at:
http://www.microsoft.com/technet/pr...in/sqlops3.mspx
HTH
Jerry
"Dan D." <DanD@.discussions.microsoft.com> wrote in message
news:056F44C1-5885-423B-A694-64200ECF196B@.microsoft.com...
> Using SS2000 SP4. We're using a .NET application. What permissions should
> be
> needed for a user to fire a trigger. Ideally, I wanted the user (userWill)
> to
> only have execute permissions on the stored procedures and select
> permissions
> on the views. But all views, stored procedures and triggers are qualified
> with "dbo".
> But when I try to update a table and the trigger fires I get these errors:
> Server: Msg 229, Level 14, State 5, Line 1
> SELECT permission denied on object 'tblFranchiseContacts', database
> 'SMCLMS_Dan', owner 'dbo'.
> Server: Msg 229, Level 14, State 1, Line 1
> UPDATE permission denied on object 'tblFranchiseContacts', database
> 'SMCLMS_Dan', owner 'dbo'.
> If I run exec sp_helpdb 'smclms_dan' I get archer\dbober as the owner.
> How do I get around this?
> Thanks,
> --
> Dan D.|||You need only to set permissions on the sprocs themselves. If the sprocs use
dynamic sql, then the tables need permissions set, too
Jeff
"Dan D." <DanD@.discussions.microsoft.com> wrote in message
news:056F44C1-5885-423B-A694-64200ECF196B@.microsoft.com...
> Using SS2000 SP4. We're using a .NET application. What permissions should
> be
> needed for a user to fire a trigger. Ideally, I wanted the user (userWill)
> to
> only have execute permissions on the stored procedures and select
> permissions
> on the views. But all views, stored procedures and triggers are qualified
> with "dbo".
> But when I try to update a table and the trigger fires I get these errors:
> Server: Msg 229, Level 14, State 5, Line 1
> SELECT permission denied on object 'tblFranchiseContacts', database
> 'SMCLMS_Dan', owner 'dbo'.
> Server: Msg 229, Level 14, State 1, Line 1
> UPDATE permission denied on object 'tblFranchiseContacts', database
> 'SMCLMS_Dan', owner 'dbo'.
> If I run exec sp_helpdb 'smclms_dan' I get archer\dbober as the owner.
> How do I get around this?
> Thanks,
> --
> Dan D.|||Thanks to you all for your replies and help.
--
Dan D.
"Jerry Spivey" wrote:

> Dan,
> If the owner of the table and the owner of the sp or view are the same the
n
> the end-user accessing the sp or view does not need to have permissions on
> the underlying tables. This provides a security abstraction layer to the
> underlying objects. However, if the owners are not the same then you have
a
> broken ownership chain in which case permissions are required. There are
no
> execute trigger permissions.
> For more information on this, see the security chapter I wrote a while bac
k
> in the SQL Server 2000 Operations Guide at:
> [url]http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlops3.mspx[/url
]
> HTH
> Jerry
> "Dan D." <DanD@.discussions.microsoft.com> wrote in message
> news:056F44C1-5885-423B-A694-64200ECF196B@.microsoft.com...
>
>

permissions for new user to use stored procedure

Using SS2000 SP4. If I have a table and revoke select, insert, update and
delete to public on the table. Then create a new user and don't give them an
y
permissions to the table. If I create stored procedures to select from,
insert into, update and delete from the table do I only have to give execute
permissions on the stored procedure to the new user for the user to be able
to execute those stored procedures? Am I correct in saying that the new user
doesn't have to have any kind of permissions on the table itself?
Thanks,
--
Dan D.That's correct. Indeed, you didn't need to revoke or deny anything on the
underlying tables, since a user has no permissions on an object by default.
All you have to do is grant EXEC permission on the proc.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Dan D." <DanD@.discussions.microsoft.com> wrote in message
news:D2083411-5A89-4F04-B1A5-373403FE75EC@.microsoft.com...
Using SS2000 SP4. If I have a table and revoke select, insert, update and
delete to public on the table. Then create a new user and don't give them
any
permissions to the table. If I create stored procedures to select from,
insert into, update and delete from the table do I only have to give execute
permissions on the stored procedure to the new user for the user to be able
to execute those stored procedures? Am I correct in saying that the new user
doesn't have to have any kind of permissions on the table itself?
Thanks,
--
Dan D.|||Wouldn't the user have permissions on the table because they are in the
'public' role by default?
Also, is the same true with views? If the user has select permission to the
view they don't need select on the underlying table?
Thanks,
--
Dan D.
"Tom Moreau" wrote:

> That's correct. Indeed, you didn't need to revoke or deny anything on the
> underlying tables, since a user has no permissions on an object by default
.
> All you have to do is grant EXEC permission on the proc.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Dan D." <DanD@.discussions.microsoft.com> wrote in message
> news:D2083411-5A89-4F04-B1A5-373403FE75EC@.microsoft.com...
> Using SS2000 SP4. If I have a table and revoke select, insert, update and
> delete to public on the table. Then create a new user and don't give them
> any
> permissions to the table. If I create stored procedures to select from,
> insert into, update and delete from the table do I only have to give execu
te
> permissions on the stored procedure to the new user for the user to be abl
e
> to execute those stored procedures? Am I correct in saying that the new us
er
> doesn't have to have any kind of permissions on the table itself?
> Thanks,
> --
> Dan D.
>|||Let's say you create a table. By default, there are no permissions on the
table - even to the public role. Same goes for any other object.
You can grant permission on a view without granting permission on the
underlying tables. (This gets messed up if you're not the owner of the
underlying tables, though.)
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Dan D." <DanD@.discussions.microsoft.com> wrote in message
news:EC40014C-0943-4CC3-9FDD-BFE610495BFD@.microsoft.com...
Wouldn't the user have permissions on the table because they are in the
'public' role by default?
Also, is the same true with views? If the user has select permission to the
view they don't need select on the underlying table?
Thanks,
--
Dan D.
"Tom Moreau" wrote:

> That's correct. Indeed, you didn't need to revoke or deny anything on the
> underlying tables, since a user has no permissions on an object by
> default.
> All you have to do is grant EXEC permission on the proc.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Dan D." <DanD@.discussions.microsoft.com> wrote in message
> news:D2083411-5A89-4F04-B1A5-373403FE75EC@.microsoft.com...
> Using SS2000 SP4. If I have a table and revoke select, insert, update and
> delete to public on the table. Then create a new user and don't give them
> any
> permissions to the table. If I create stored procedures to select from,
> insert into, update and delete from the table do I only have to give
> execute
> permissions on the stored procedure to the new user for the user to be
> able
> to execute those stored procedures? Am I correct in saying that the new
> user
> doesn't have to have any kind of permissions on the table itself?
> Thanks,
> --
> Dan D.
>|||I understand. Thanks.
--
Dan D.
"Tom Moreau" wrote:

> Let's say you create a table. By default, there are no permissions on the
> table - even to the public role. Same goes for any other object.
> You can grant permission on a view without granting permission on the
> underlying tables. (This gets messed up if you're not the owner of the
> underlying tables, though.)
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Dan D." <DanD@.discussions.microsoft.com> wrote in message
> news:EC40014C-0943-4CC3-9FDD-BFE610495BFD@.microsoft.com...
> Wouldn't the user have permissions on the table because they are in the
> 'public' role by default?
> Also, is the same true with views? If the user has select permission to th
e
> view they don't need select on the underlying table?
> Thanks,
> --
> Dan D.
>
> "Tom Moreau" wrote:
>
>

permissions for drive where data is

Using SS2000 SP4. I have an account called "sqlserver" that I use to start
the SQL Server service and the SQL Server Agent service. This account is an
admin account in sql server. I moved a database from one drive to a new
drive. The database came up as read-only. The permissions on both drives are
the same.
Any ideas why the database came up read-only?
Thanks,
--
Dan D.I just tried to detach the database again in code and got messages like these:
Running UPDATE STATISTICS on all tables
Updating dbo.dtproperties
Server: Msg 3906, Level 16, State 1, Line 1
Could not run BEGIN TRANSACTION in database 'promo2007' because the database
is read-only.
I then tried to take the database offline in EM and it said the database
didn't exist. I then tried to rename the MDF file and I was able to.
Can I create a new database with the same name, detach it and put the
original MDF file in place and attach it again?
Thanks,
--
Dan D.
"Dan D." wrote:
> Using SS2000 SP4. I have an account called "sqlserver" that I use to start
> the SQL Server service and the SQL Server Agent service. This account is an
> admin account in sql server. I moved a database from one drive to a new
> drive. The database came up as read-only. The permissions on both drives are
> the same.
> Any ideas why the database came up read-only?
> Thanks,
> --
> Dan D.|||I ran the reattachment again and it was okay.
--
Dan D.
"Dan D." wrote:
> Using SS2000 SP4. I have an account called "sqlserver" that I use to start
> the SQL Server service and the SQL Server Agent service. This account is an
> admin account in sql server. I moved a database from one drive to a new
> drive. The database came up as read-only. The permissions on both drives are
> the same.
> Any ideas why the database came up read-only?
> Thanks,
> --
> Dan D.

permissions for drive where data is

Using SS2000 SP4. I have an account called "sqlserver" that I use to start
the SQL Server service and the SQL Server Agent service. This account is an
admin account in sql server. I moved a database from one drive to a new
drive. The database came up as read-only. The permissions on both drives are
the same.
Any ideas why the database came up read-only?
Thanks,
Dan D.
I just tried to detach the database again in code and got messages like these:
Running UPDATE STATISTICS on all tables
Updating dbo.dtproperties
Server: Msg 3906, Level 16, State 1, Line 1
Could not run BEGIN TRANSACTION in database 'promo2007' because the database
is read-only.
I then tried to take the database offline in EM and it said the database
didn't exist. I then tried to rename the MDF file and I was able to.
Can I create a new database with the same name, detach it and put the
original MDF file in place and attach it again?
Thanks,
Dan D.
"Dan D." wrote:

> Using SS2000 SP4. I have an account called "sqlserver" that I use to start
> the SQL Server service and the SQL Server Agent service. This account is an
> admin account in sql server. I moved a database from one drive to a new
> drive. The database came up as read-only. The permissions on both drives are
> the same.
> Any ideas why the database came up read-only?
> Thanks,
> --
> Dan D.
|||I ran the reattachment again and it was okay.
Dan D.
"Dan D." wrote:

> Using SS2000 SP4. I have an account called "sqlserver" that I use to start
> the SQL Server service and the SQL Server Agent service. This account is an
> admin account in sql server. I moved a database from one drive to a new
> drive. The database came up as read-only. The permissions on both drives are
> the same.
> Any ideas why the database came up read-only?
> Thanks,
> --
> Dan D.

permissions for drive where data is

Using SS2000 SP4. I have an account called "sqlserver" that I use to start
the SQL Server service and the SQL Server Agent service. This account is an
admin account in sql server. I moved a database from one drive to a new
drive. The database came up as read-only. The permissions on both drives are
the same.
Any ideas why the database came up read-only?
Thanks,
--
Dan D.I just tried to detach the database again in code and got messages like thes
e:
Running UPDATE STATISTICS on all tables
Updating dbo.dtproperties
Server: Msg 3906, Level 16, State 1, Line 1
Could not run BEGIN TRANSACTION in database 'promo2007' because the database
is read-only.
I then tried to take the database offline in EM and it said the database
didn't exist. I then tried to rename the MDF file and I was able to.
Can I create a new database with the same name, detach it and put the
original MDF file in place and attach it again?
Thanks,
--
Dan D.
"Dan D." wrote:

> Using SS2000 SP4. I have an account called "sqlserver" that I use to start
> the SQL Server service and the SQL Server Agent service. This account is a
n
> admin account in sql server. I moved a database from one drive to a new
> drive. The database came up as read-only. The permissions on both drives a
re
> the same.
> Any ideas why the database came up read-only?
> Thanks,
> --
> Dan D.|||I ran the reattachment again and it was okay.
--
Dan D.
"Dan D." wrote:

> Using SS2000 SP4. I have an account called "sqlserver" that I use to start
> the SQL Server service and the SQL Server Agent service. This account is a
n
> admin account in sql server. I moved a database from one drive to a new
> drive. The database came up as read-only. The permissions on both drives a
re
> the same.
> Any ideas why the database came up read-only?
> Thanks,
> --
> Dan D.