Hi all,
I am trying to run a DTS package from a Batcch file. I coded the batch file
as follows:
dtsrun /s sqlserver /e /n "currents_import" /U Acctname /P password
pause

The username and password are the same as the owner of the package. Does it
matter the user is not logged onto her machine as the owner?
What rights does a non SA need to run this package when they log into thier
machine NOT as the owner?

TIA,
Joe

Hello jaylou,

The U and the P here are ONLY to get onto the SQL Server housing the packages.
They have nothing to do with the package per se. The connections within
the package determine what credentials are used and whether you can connect
to something.

Allan

Thank you, That explains the reason I can execute the package and the user
can't.

Do you know if there is a server role that will allow the user to run a DTS
package that she is not the owner of?
Thanks again,
Joe

"Allan Mitchell" wrote:

Hello jaylou,

The package owner is more or less a "Non problem".

Package Ownership Issues
(http://www.sqldts.com/default.aspx?212)

If your user cannot execute the package then from your syntax (more in a
bit) they are not authenticating to the SQL Server as a whole.

In your syntax you specify a trusted connection tothe sql server AND use
sql server credentials. Both are not necessary.


Allan

Thank you,
I read the document but it doesn't say what rights the user needs.
She is a datareader of the Database this pacakage hits. and she is in the
msdb database as public.

I will do more testing with my user name and password on a dev box to see if
there is any other roles she will need.

Thanks,
Joe

"Allan Mitchell" wrote:

Hello jaylou,

Public is in MSDB and can by default do everything with DTS packages. So
long as the user is on the server they are good so no need to put the user
themselves in there. What is the error you see? If the connections in the
package are using trusted authentication and the user is only a datareader
on the sources to the data what is the destination?

Allan

I am not sure of the exact error, but it was that the user did not have
rights to the table in the database. the table is a temp table that is
dropped and recreated at the begining of the run. she is a datareader on the
destination database, and she has full rights to the excel spreadsheet that
is being imported into the temp table.

I am baffled with this one.

"Allan Mitchell" wrote: