DTS schedule and oracle

Here's a weird problem. I've read everything I could find about permissions and scheduling a DTS but I'm still having problems. I've created a DTS on my production server (Windows 2000 Server) and it runs fine when I'm running it on the server. (I'm at the machine) When I schedule it, it starts to run and then it just hangs on step one. I tried removing steps from my dts to see which one is causing the problem and through process of elimination I found it was the step that connects to my oracle server. When I run the DTS manually I am logged in as SJKAdmin and the SQLServer Agent account is SQLAdmin. Both users are local administrators on both the production server and the server where the oracle DB is. I just can't figure it out. The real kicker is that I have a development server set up that's supposed to be identical to the production server and both the DTS (when run manually) and the scheduled jobs run without any problem. Any help would be greatly appreciated.

BrettHave you logged into the production server (@. the prodution server) as SQLAdmin and gone into Oracles Net Manager and tested the connection?

DTS permissions?

i posted this in programming but nobody answered so I thought I might try he
re aswell.
Can anyone help us with the following...
we've got lots of DTS packages stored on SQL server, however we have noticed
that it takes the login credentials for what to save the DTS package owner
as from windows, and not from the SQL server login that you type in to save
it. EVEN though we have got
the SQL server installation set to not allow trusted connections.
What we are trying to do is get it so we can save each other's DTS packages
without being members of the sysadmin role. Is there anyway we can do it?
The dba (rightly) doesn't want to give us all sa rights, and we can't switch
over to windows authentication until we get our own domain (which is months
off), as otherwise we would have to give the IT department's domain adminis
trators access to our serve
rs, which we don't want to do.
Any other way round it?
The dba's just come up with some 'undocumented stored procedure' that might
enable us to change things in some way but he's going to let me have a look
after lunch, but has anybody else experienced this problem?BOL refers:
Usually, a package run from DTS Designer, the DTS Import/Export Wizard, the
DTS Run utility, or from the command prompt executes under the security cont
ext of the user who is currently logged in. However, a package scheduled for
execution runs under the s
ecurity context of the SQL Server Agent job that runs the package. The owner
of that job may or may not be the same as the user currently logged in.
For packages created under a Microsoft Windows NT? 4.0 or Microsoft Windows
? 2000 account, the job runs under the security context of the account that
started SQL Server Agent.
If the job is owned by a login belonging to the sysadmin fixed server role,
the security context of the package defaults to the account used to start th
e local SQL Server Agent. If the server is registered using Windows Authenti
cation, the owner of the jo
b is the account of the SQL Server Agent. If the server is registered using
SQL Server Authentication, the owner of the job is that SQL Server login.
If the job is owned by a login that is not a member of the sysadmin fixed se
rver role, the package runs under the context of the job step proxy account,
with the rights and permissions of that account.
--
Satya SKJ
"Beeeeeeeeeeeeves" wrote:

> i posted this in programming but nobody answered so I thought I might try
here aswell.
> Can anyone help us with the following...
> we've got lots of DTS packages stored on SQL server, however we have noticed that
it takes the login credentials for what to save the DTS package owner as from window
s, and not from the SQL server login that you type in to save it. EVEN though we hav
e g
ot the SQL server installation set to not allow trusted connections.
> What we are trying to do is get it so we can save each other's DTS package
s without being members of the sysadmin role. Is there anyway we can do it?
> The dba (rightly) doesn't want to give us all sa rights, and we can't switch over
to windows authentication until we get our own domain (which is months off), as othe
rwise we would have to give the IT department's domain administrators access to our
ser
vers, which we don't want to do.
> Any other way round it?
> The dba's just come up with some 'undocumented stored procedure' that migh
t enable us to change things in some way but he's going to let me have a loo
k after lunch, but has anybody else experienced this problem?
>|||Not helpful, please don't just quote BOL.
Re-read the question and re-consider whether your answer comes even vaguely
close to answering it, in case you didn't work it out, the answer is no.
The question was HOW CAN WE SAVE EACH OTHER'S PACKAGES. I also clearly state
d that the server is NOT windows authentication, and the users that the prob
lem affects are NOT members of the sysadmin role. Yet you chose to rabble on
(or copy and paste text th
at rabbles on) about "if you are using windows authentication" and "if you a
re in the sysadmin role".
The answer seems to be to save it in metadata services rather than local pac
kages.|||"When saving a local package Enterprise Manager calls sp_add_dtspackage
found in the msdb database. If you are not the owner and not a member of the
sysadmin role an error will be returned. If you fail this check the error
"Only the owner of DTS Package 'MyPackage' or a member of the sysadmin role
may create new versions of it." will be returned. A similar check is
contained within sp_drop_dtspackage which is used when deleting a package.
If multiple non-sysadmin developers all need to work on the same package
this limitation can cause major problems. One totally unsupported workaround
would be to remove the checks from the stored procedure. I have implemented
this successfully in development environments where teams all need to work
with the same packages, without any problems. "
The undocumented proc will sp_reassign_dtspackageowner, but that is no use
in a dev shop, as it bneeds running each time a package has been saved and a
new user wants access.
Package Ownership Issues
(http://www.sqldts.com/default.aspx?212)
Darren Green
http://www.sqldts.com
"Beeeeeeeeeeeeves" <Beeeeeeeeeeeeves@.discussions.microsoft.com> wrote in
message news:65E2ED1D-0810-4044-B8EE-342171657FB8@.microsoft.com...
> Not helpful, please don't just quote BOL.
> Re-read the question and re-consider whether your answer comes even
vaguely close to answering it, in case you didn't work it out, the answer is
no.
> The question was HOW CAN WE SAVE EACH OTHER'S PACKAGES. I also clearly
stated that the server is NOT windows authentication, and the users that the
problem affects are NOT members of the sysadmin role. Yet you chose to
rabble on (or copy and paste text that rabbles on) about "if you are using
windows authentication" and "if you are in the sysadmin role".
> The answer seems to be to save it in metadata services rather than local
packages.
>|||Ah ... does it! cheers. I'll check that out as a potential loophole as all u
s devs have been made dbo of msdb.
Cheers
"Darren Green" wrote:

> "When saving a local package Enterprise Manager calls sp_add_dtspackage
> found in the msdb database. If you are not the owner and not a member of t
he
> sysadmin role an error will be returned. If you fail this check the error
> "Only the owner of DTS Package 'MyPackage' or a member of the sysadmin rol
e
> may create new versions of it." will be returned. A similar check is
> contained within sp_drop_dtspackage which is used when deleting a package.
> If multiple non-sysadmin developers all need to work on the same package
> this limitation can cause major problems. One totally unsupported workarou
nd
> would be to remove the checks from the stored procedure. I have implemente
d
> this successfully in development environments where teams all need to work
> with the same packages, without any problems. "
> The undocumented proc will sp_reassign_dtspackageowner, but that is no use
> in a dev shop, as it bneeds running each time a package has been saved and
a
> new user wants access.
> Package Ownership Issues
> (http://www.sqldts.com/default.aspx?212)
>
> --
> Darren Green
> http://www.sqldts.com
> "Beeeeeeeeeeeeves" <Beeeeeeeeeeeeves@.discussions.microsoft.com> wrote in
> message news:65E2ED1D-0810-4044-B8EE-342171657FB8@.microsoft.com...
> vaguely close to answering it, in case you didn't work it out, the answer
is
> no.
> stated that the server is NOT windows authentication, and the users that t
he
> problem affects are NOT members of the sysadmin role. Yet you chose to
> rabble on (or copy and paste text that rabbles on) about "if you are using
> windows authentication" and "if you are in the sysadmin role".
> packages.
>
>

DTS permissions to create

How to I revoke the ability of non-sa non-dbo users from
creating DTS packages on a SQL 2000 server?
Thx!
You could try revoking or denying write permissions to msdb. this is where dts package information is stored I believe.
In theory the creation of a package should fail if it cannot be written to msdb.
"Angelina" wrote:

> How to I revoke the ability of non-sa non-dbo users from
> creating DTS packages on a SQL 2000 server?
> Thx!
>
|||There's no specific stored procedure in msdb that I can
explicity deny that creates the DTS packages?

>--Original Message--
>You could try revoking or denying write permissions to
msdb. this is where dts package information is stored I
believe.
>In theory the creation of a package should fail if it
cannot be written to msdb.[vbcol=seagreen]
>"Angelina" wrote:
from
>.
>
|||Angelina
To prevent users from adding DTS packages, you can deny EXEC permissions on
sp_add_dtspackage. Deny exec on sp_enum_dtspackages should stop users
browsing packages.
HTH,
Paul Ibison
|||Thanks Paul,
Do I Deny the permissions to the guest account.
There are no actual users in the msdb database besides
guest and dbo. Or can I remove the guest account
completely. What's recommended?

>--Original Message--
>Angelina
>To prevent users from adding DTS packages, you can deny
EXEC permissions on
>sp_add_dtspackage. Deny exec on sp_enum_dtspackages
should stop users
>browsing packages.
>HTH,
>Paul Ibison
>
>.
>
|||The rights are inherited by virtue of the guest user and the permissions of
the public role. The way I'd do it is remove (revoke and not deny) the exec
rights from the public role and then create your own role with exec rights
to the 2 procedures I mentioned. If a user needs to be able to use them,
then add him explicitly as a user in MSDB and into your role.
HTH,
Paul Ibison

DTS permissions to create

How to I revoke the ability of non-sa non-dbo users from
creating DTS packages on a SQL 2000 server?
Thx!You could try revoking or denying write permissions to msdb. this is where d
ts package information is stored I believe.
In theory the creation of a package should fail if it cannot be written to m
sdb.
"Angelina" wrote:

> How to I revoke the ability of non-sa non-dbo users from
> creating DTS packages on a SQL 2000 server?
> Thx!
>|||There's no specific stored procedure in msdb that I can
explicity deny that creates the DTS packages?

>--Original Message--
>You could try revoking or denying write permissions to
msdb. this is where dts package information is stored I
believe.
>In theory the creation of a package should fail if it
cannot be written to msdb.
>"Angelina" wrote:
>
from[vbcol=seagreen]
>.
>|||Angelina
To prevent users from adding DTS packages, you can deny EXEC permissions on
sp_add_dtspackage. Deny exec on sp_enum_dtspackages should stop users
browsing packages.
HTH,
Paul Ibison|||Thanks Paul,
Do I Deny the permissions to the guest account.
There are no actual users in the msdb database besides
guest and dbo. Or can I remove the guest account
completely. What's recommended?

>--Original Message--
>Angelina
>To prevent users from adding DTS packages, you can deny
EXEC permissions on
>sp_add_dtspackage. Deny exec on sp_enum_dtspackages
should stop users
>browsing packages.
>HTH,
>Paul Ibison
>
>.
>|||The rights are inherited by virtue of the guest user and the permissions of
the public role. The way I'd do it is remove (revoke and not deny) the exec
rights from the public role and then create your own role with exec rights
to the 2 procedures I mentioned. If a user needs to be able to use them,
then add him explicitly as a user in MSDB and into your role.
HTH,
Paul Ibison

DTS permissions to create

How to I revoke the ability of non-sa non-dbo users from
creating DTS packages on a SQL 2000 server?
Thx!There's no specific stored procedure in msdb that I can
explicity deny that creates the DTS packages?
>--Original Message--
>You could try revoking or denying write permissions to
msdb. this is where dts package information is stored I
believe.
>In theory the creation of a package should fail if it
cannot be written to msdb.
>"Angelina" wrote:
>> How to I revoke the ability of non-sa non-dbo users
from
>> creating DTS packages on a SQL 2000 server?
>> Thx!
>.
>|||Angelina
To prevent users from adding DTS packages, you can deny EXEC permissions on
sp_add_dtspackage. Deny exec on sp_enum_dtspackages should stop users
browsing packages.
HTH,
Paul Ibison|||Thanks Paul,
Do I Deny the permissions to the guest account.
There are no actual users in the msdb database besides
guest and dbo. Or can I remove the guest account
completely. What's recommended?
>--Original Message--
>Angelina
>To prevent users from adding DTS packages, you can deny
EXEC permissions on
>sp_add_dtspackage. Deny exec on sp_enum_dtspackages
should stop users
>browsing packages.
>HTH,
>Paul Ibison
>
>.
>|||The rights are inherited by virtue of the guest user and the permissions of
the public role. The way I'd do it is remove (revoke and not deny) the exec
rights from the public role and then create your own role with exec rights
to the 2 procedures I mentioned. If a user needs to be able to use them,
then add him explicitly as a user in MSDB and into your role.
HTH,
Paul Ibison

DTS permissions and ownership

We have a DTS package developed on our development PC's (SQL 7). It
runs fine. When we schedule it on the server (SQL 7), it fails. We
have been able to find that this is a known issue down to the use of
permissions (running it uses the users permissions, scheduling it uses
the servers). http://support.microsoft.com/?kbid=269074

Our Ops Support team insist that we have the full permissions to run
this, but it still fails. If we log on to the server as the service
and re-create (sample) the DTS package, we can schedule it. However,
we don't want to have to go the the comms room (or use VNC) to develop
DTS packages. If we then change this on our development PC's we get
the same problem as we appear to have taken ownership. It looks like
ownership is not just on the DTS package, but on the components as
well.

Is there are way of changing the ownership of the DTS package /
components ?

What can I check with regards permissions ?

Any help would be appreciated.

Thanks

RyanManaged to find the answer. It was down to a different version of
MDAC.
Ver 2.5 was on the server and 2.6 was on the development PC's. With
the connection properties, additional information is passed with 2.6
which causes a problem with 2.5

When executing the DTS package, it uses the current PC's version. When
scheduled, it uses the version on the server.

The way around this was to re-do the connection properties while
logged on the server (using VNC) and then save it.

Now we know what needs doing, we'll get all of the PC's & servers
checked and put on the same version.

R

ryanofford@.hotmail.com (Ryan) wrote in message news:<7802b79d.0404190132.4438ecc2@.posting.google.com>...
> We have a DTS package developed on our development PC's (SQL 7). It
> runs fine. When we schedule it on the server (SQL 7), it fails. We
> have been able to find that this is a known issue down to the use of
> permissions (running it uses the users permissions, scheduling it uses
> the servers). http://support.microsoft.com/?kbid=269074
> Our Ops Support team insist that we have the full permissions to run
> this, but it still fails. If we log on to the server as the service
> and re-create (sample) the DTS package, we can schedule it. However,
> we don't want to have to go the the comms room (or use VNC) to develop
> DTS packages. If we then change this on our development PC's we get
> the same problem as we appear to have taken ownership. It looks like
> ownership is not just on the DTS package, but on the components as
> well.
> Is there are way of changing the ownership of the DTS package /
> components ?
> What can I check with regards permissions ?
> Any help would be appreciated.
> Thanks
>
> Ryansqlsql

DTS permissions

I would like to import data from Source database into Target using DTS, what are the minimum SQL Server 2K privileges/server roles required for regular user to achieve that on both Source and Target instances? This import will replace existing objects on Target.

Thanks

As a client side tool, the minimum needed would be the same as if you were executing the SQL statements from any other tool. You'd need permissions to connect to the source, access the database, read from the table/view or execute whatever stored procedure. On the target, you'd need to be able to drop and create whatever objects are involved, insert into the table, etc.

-Sue

|||

There are also mulitple ways of doing this - if you're talking about transferring data between SQL Server databases, then Sue is correct. You can also export the data from the source server and store it as a file to be imported into the target. In that case, you have a lot of options, from file permissions to FTP security.

|||I was trying to use DTS in order to copy database objects from source to target, using drop target objects before copy option. In both databases user was db_owner however when I tried using DTS it was giving error saying that I need to have sysadmin privileges and sure enough as soon as I granted that to a user it worked. I also think that is overkill because I don't want developers working with DTS packages getting almighty privs.

DTS Permissions

Hello all

Hope someone can help, I have set up a new user and restricted his acces to the db,

how can I allow him to read DTS packages but not change or execute them?

Thanks

Richard

Hey Richie,

Which version of SQL Server are you using?|||IF those DTS package is owned by SA and scheduled as a job then you need to give this user permission in TARGETSERVERROLE role.

DTS Permissions

Hello all

Hope someone can help, I have set up a new user and restricted his acces to the db,

how can I allow him to read DTS packages but not change or execute them?

Thanks

Richard

Hey Richie,

Which version of SQL Server are you using?|||IF those DTS package is owned by SA and scheduled as a job then you need to give this user permission in TARGETSERVERROLE role.

DTS Permissions

Assuming you can open the package, simply click on
package in the upper left and save as...
>--Original Message--
>We have a DTS package that was created and saved by
>someone who is no longer with the company. How can we
>convert this DTS package to a valid ID? Thanks
>.
>try sp_reassign_dtspackageowner
Olu Adedeji
"Peter Cwik" <anonymous@.discussions.microsoft.com> wrote in message
news:155bb01c3fa49$ecf965f0$a601280a@.phx
.gbl...
> Assuming you can open the package, simply click on
> package in the upper left and save as...

DTS Permissions

We have a DTS package that was created and saved by
someone who is no longer with the company. How can we
convert this DTS package to a valid ID? ThanksHi Natalie
I am reviewing your post and our community members provide some good
suggestions to your problem. Have you try these methods? Do they resolve
problem? If you still have any questions about it, please feel free to post
message here and we are glad to help!
Looking forward to hearing from you. Thanks.
Best regards
Baisong Wei
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.sqlsql

DTS Packages

I am new to SQL but have been tasked with setting up an SQL server. I have
setup a basic database and applied appropriate permissions. The problem is
that one of our analysts says that I am unable to maintian our policy of
giving limited permissions/access to create DTS packages without giving up
full Server control. His reasoning is that if you have the ability to create
DTS packages, you then have access to the command prompt and therefore to
system commands. Is there anyway to give a user the ability to create DTS
packages without giving up Server control, or creating security risk
problems'
Any help will be appreciated.
Thanks in advance.By default, anyone with access to SQL Server can save a DTS package to the
local repository. This does not in any way provide access to a command
prompt.
Perhaps the analyst is referring to creating SQL Server Agent jobs that run
DTS packages using the DTSRUN command-line utility in a CMDEXEC job step.
This is not allowed by default. You need to explicitly allow non-symins
to execute cmdexec job steps and specify a proxy account as the security
context. This would allow non-symins to execute command-line utilities
like DTSRUN yet be limited to the security context of the proxy account you
specify. The proxy account is usually a minimally privileged account. See
the Books Online for more information.
If SQL Agent scheduling is not a requirement, the DTS can be run
interactively (where it runs on the user machine) or scheduled by another
means.
Hope this helps.
Dan Guzman
SQL Server MVP
"r2d2" <John.Infotech@.gmail.com> wrote in message
news:eInzqH3xFHA.448@.TK2MSFTNGP11.phx.gbl...
>I am new to SQL but have been tasked with setting up an SQL server. I have
>setup a basic database and applied appropriate permissions. The problem is
>that one of our analysts says that I am unable to maintian our policy of
>giving limited permissions/access to create DTS packages without giving up
>full Server control. His reasoning is that if you have the ability to
>create DTS packages, you then have access to the command prompt and
>therefore to system commands. Is there anyway to give a user the ability
>to create DTS packages without giving up Server control, or creating
>security risk problems'
> Any help will be appreciated.
> Thanks in advance.
>

dts or xp_cmdshell permissions

How do i give a user permissions to execute XP_CMDSHELL or a DTS package?
Without compromising the systems security.
Basically what im trying to do is use an asp page on another domain to
access mssql and create a database. Everything works fine except that i
cannot create a folder on the server.
I need to first create a folder by passing the domain name to xp_cmdshell on
the local drive. Then creating the database.
The account accessing the mssql server is dbm.something.com which is in the
master database. This sends arguments to a stores procedure that creates the
database. I added a line to the stored procedure to run xp_cmdshell and
create a database. Once it gets to this line it gives me an error
xpsql.c:Error 1314 from CreateProcessAsUser on line: 432.
Please help me
Thank you
The error 1314 you are getting is:
A required privilege is not held by the client.
Could be that your SQL service account doesn't have the
correct rights to allow it to change security context to the
proxy account. The SQL service account needs Act as part of
OS, Increase Quotas, replace process level token and Login
as batch job.
-Sue
On Wed, 21 Sep 2005 16:15:04 -0400, "robert" <rob@.ms.com>
wrote:

>How do i give a user permissions to execute XP_CMDSHELL or a DTS package?
>Without compromising the systems security.
>Basically what im trying to do is use an asp page on another domain to
>access mssql and create a database. Everything works fine except that i
>cannot create a folder on the server.
>I need to first create a folder by passing the domain name to xp_cmdshell on
>the local drive. Then creating the database.
>The account accessing the mssql server is dbm.something.com which is in the
>master database. This sends arguments to a stores procedure that creates the
>database. I added a line to the stored procedure to run xp_cmdshell and
>create a database. Once it gets to this line it gives me an error
>xpsql.c:Error 1314 from CreateProcessAsUser on line: 432.
>Please help me
>Thank you
>
|||Yeah i read that somewhere, but i dont know how to give it the permissions.
Where do i do that ? act as part of OS and logon as batch are windows
permissions. I dont have a proxy account for SQL under the local users or
domain users. What am i missing here?
Thank for helping
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:feijj1dvrbpvrjepce3jrvqbkj2pdi6l6e@.4ax.com...
> The error 1314 you are getting is:
> A required privilege is not held by the client.
> Could be that your SQL service account doesn't have the
> correct rights to allow it to change security context to the
> proxy account. The SQL service account needs Act as part of
> OS, Increase Quotas, replace process level token and Login
> as batch job.
> -Sue
> On Wed, 21 Sep 2005 16:15:04 -0400, "robert" <rob@.ms.com>
> wrote:
>
|||First, your missing the rights for the service account. The
permissions are outlined in the following article but if you
set the service accounts through Enterprise Manager, the
rights and permissions are handled for you:
HOW TO: Change the SQL Server or SQL Server Agent Service
Account Without Using SQL Enterprise Manager in SQL Server
2000
http://support.microsoft.com/?id=283811
You can use the Local Security Policy snap in to view the
permissions. From the run command from the start button,
type in secpol.msc
If accounts other than sysadmin accounts or the service
accounts are going to be used to execute xp_cmdshell, you
need to setup a proxy account. You can use
xp_sqlagent_proxy_account
You can find more information in books online under
xp_sqlagent_proxy_account and xp_cmdshell.
-Sue
On Wed, 28 Sep 2005 12:18:24 -0400, <rvegas@.rogers.com>
wrote:

>Yeah i read that somewhere, but i dont know how to give it the permissions.
>Where do i do that ? act as part of OS and logon as batch are windows
>permissions. I dont have a proxy account for SQL under the local users or
>domain users. What am i missing here?
>Thank for helping
>"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
>news:feijj1dvrbpvrjepce3jrvqbkj2pdi6l6e@.4ax.com.. .
>
|||Thanx for your help Sue, still a bit confused will have to read up on this.
Under enterprise manager >>management>sqlserver agent>job system tab.
I have "only sysadmins can run active scripting jobs" checked. I dont want
to change this. Is there another way?
Sorry for all the stupid questions. just dont want to mess anything up.
Thanx
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:55jlj1p4m2s30gcolq6i9ok7gqcs16vjjj@.4ax.com...
> First, your missing the rights for the service account. The
> permissions are outlined in the following article but if you
> set the service accounts through Enterprise Manager, the
> rights and permissions are handled for you:
> HOW TO: Change the SQL Server or SQL Server Agent Service
> Account Without Using SQL Enterprise Manager in SQL Server
> 2000
> http://support.microsoft.com/?id=283811
> You can use the Local Security Policy snap in to view the
> permissions. From the run command from the start button,
> type in secpol.msc
> If accounts other than sysadmin accounts or the service
> accounts are going to be used to execute xp_cmdshell, you
> need to setup a proxy account. You can use
> xp_sqlagent_proxy_account
> You can find more information in books online under
> xp_sqlagent_proxy_account and xp_cmdshell.
> -Sue
> On Wed, 28 Sep 2005 12:18:24 -0400, <rvegas@.rogers.com>
> wrote:
>
|||No problem. You could have the users execute the package
using the DTS object model. There are a few different
options with that and you could use another application such
as ASP. The following have some examples:
Execute a package with OLE Automation -
http://www.databasejournal.com/featu...le.php/1459181
Execute a package from ASP -
http://www.sqldts.com/default.aspx?207
Execute a package from VB -
http://www.sqldts.com/default.aspx?208
-Sue
On Fri, 7 Oct 2005 16:56:33 -0400, <rvegas@.rogers.com>
wrote:

>Thanx for your help Sue, still a bit confused will have to read up on this.
>Under enterprise manager >>management>sqlserver agent>job system tab.
>I have "only sysadmins can run active scripting jobs" checked. I dont want
>to change this. Is there another way?
>Sorry for all the stupid questions. just dont want to mess anything up.
>Thanx
>"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
>news:55jlj1p4m2s30gcolq6i9ok7gqcs16vjjj@.4ax.com.. .
>