I have SSIS 2012 package which runs SQL command by executing SQLCMD command line utility with -E switch. This switch means that it should use trusted connection to connect to SQL server.
The problem is that if i try to run package directly through Object Explorer, i get ANONYMOUS LOGON error. I get the same error running package using stored procedures.
The only way i can run it is through SQL Server Agent Job which then uses SQL Server Agent login.
The question is how to run package using stored procedures with some user which will be used for trusted connection?
Two options. For your manual executions, you'll need to use [RunAs][1] command to launch the dtexec process as the desired user. Covered it a bit in this answer Deploying SSIS (SQL Server 2012) Project Outside Network
For scheduled executions, you'll need to create the appropriate stored credentials within SQL Server, authorize those credentials for use with jobs of type SSIS and then create your job using those stored credentials.
Related
Could anyone please help me to understand this code under SQL-Server Job steps. One of the step having this process and I am not getting its process behavior with Type - "Operating System (CmdExe)" and Run-as - "SQL Server Agent Service Account".
Also, What is the actual role of these Type & Run-as in option?
Run as defines the proxy account to be used to run this step. Proxy accounts defines a security context in which this job step runs. Each proxy corresponds to a security credential. For example, if you try to execute a copy command with CmdExec type, you must use a credential (e.g. Windows user account) that has rights to read the source file and rights to write in the destination folder.
Job steps can be different types:
Executable programs and operating system commands.
Transact-SQL statements, including stored procedures and extended stored procedures.
PowerShell scripts.
Microsoft ActiveX scripts.
Replication tasks.
Analysis Services tasks.
Integration Services packages.
Each type is executed differently. T-SQL scripts are sent to the database engine, executable programs (CmdExec) starts external programs (e.g. copy to copy files, or DTSRun to run a DTS package outside of SQL Server, as in your example), etc.
Requirements - Schedule task in SQL Express Edition.
But SQL server Agent functionality is not available in express edition.
Possible Solution- Schedule batch file execution to execute sql script. Tried
Batch File-cmd /k sqlcmd -i backup.sql
Sql Script-backup database DB_user1212 to disk = 'E:\backups\MyBackup.bak'. But error occurred while executing sql script A network related or instance specific error occurred while establishing a connection to SQL Server
Possible Reason- Something like connection string missing. Help me how to solve this, i am using windows authentication for connection.
All you need to do is add the additional parameters to your call to sqlcmd.
sqlcmd -S yoursqlserver -E -i C:\pathto\backup.sql
I Have Created SSIS package which selects data from Source DB and Inserts it in my Destination DB. All the Connections string are Working fine as the Test Connection is Succeeded when i debug the package.
My package Executes well when i run it in Visual Studio. But If i try to run it as Scheduled Job in SQL Server . It gives me error as
Data Flow Task ADO NET Source [1] "Login Failed for user 'ags' for
Source Database"
My Source DB is remotely Located.
Package Settings :
EncryptAllWithPassword
SQL Agent Settings
Owner : uagsrep (My SQL Server User)
Type : SQL Server Integration Service Package
Run AS : SQL Server Agent Service Account
Database is SQL Server 2008
SQL Server Job executes SSIS Package using System Account. Check if System account has permission on Source Database.
Refer: Running SSIS Package using Non System Account
Ok so I asked a question yesterday about doing a timed procedure. I got some responses about using SQL Server Agent but i found out that I am using Sql server 2008 express RC and its not available.
Here is my first question and I want to know if there is another tool I can use to do a timed procedure with sql server ....thanks again
You can use dialog timers to start activated procedures. This functionality is available on the Express edition. The advantage over an external service, like Windows Scheduler, is that the solution is self contained inside the database. For example you can move the database to a different computer and the timed procedure will still run, on the new computer, once the database is started. An external service requires you to reconfigure the scheduler agent on the new computer.
You can use scheduled task (control panel-administrative tools) and start a .cmd/.bat file where you use sqlcmd to execute SP's or run scripts.
sqlcmd is a command line tool. sqlcmd /? will show you what you can do with it.
Here is how you can use sqlcmd to execute a SP called StoredProcName in database YourDatabase on server instance ComputerName\sqlexpress.
sqlcmd -S ComputerName\sqlexpress -E -d YourDatabase -Q "exec StoredProcName"
Read more about Using the sqlcmd Utility here http://msdn.microsoft.com/en-us/library/ms180944.aspx
Read about the Task Scheduler here http://msdn.microsoft.com/en-us/library/aa383614%28v=vs.85%29.aspx.
I'm try to figure how to create sql server stored procedure that when a condition is met executes an executable, with command line arguments, on a remote machine within the network. I could write my own little server application to handle the communication sent from the stored procedure for the executable, but I'm not certain if socket programming is a reasonable option with sql server. Any direction would be helpful.
You'd need some server-side application anyway, even if that application were SQL Server :)
Something like rsh might do - have your local SQL instance invoke xp_cmdshell with an rsh command (or a batch file), connecting to the remote server and executing the command.
If you have SQL on the remote machine, it'd be far easier; call a stored procedure on that machine from the local machine, and let that stored procedure do the work (might need fiddling with proxies and "execute as").
A third option would be to create a .NET stored procedure, and do your socket programming or remote invocation from there - it runs in-process, so you get similar same performance and security benefits you'd get from writing it in T-SQL rather than hopping out to a cmdshell with all the mess that entails.