I have question regarding SSIS. I have csv source files dumped at server xyz, and I have developed package. Now I want to deploy it to SQL Server box (server pqr) to run via job scheduler.
My question is are those files need to be present on the SQL Server box? Or account which runs job scheduler should be given access to location of file path mentioned in conn. manager of pkg?
I am newbee to ssis..
Thanks Regards,
Chaitanya
Account that the Job Scheduler is running from should have appropriate access to folder (local or network) with csv files. Path to CSV files should be successfully resolved from the Job Scheduler location: C:\temp\test.csv or \\servername\sharename\test.csv.
If you've tried and job failed, please provide the error message.
Related
I have created a SSIS Execute Task package to export CSV and write into d:/ drive
It works when i execute from SSIS.However when i run from SQLServer agent, the job shows sucess but the export file is not available in the location
Can anyone please advise if anything i am missing.
Thank you
I think that the issue is that the SQL agent doesn't have access to the file system location. Make sure that SQL service account has needed permissions:
Configure File System Permissions for Database Engine Access
I am trying to create a simple SSIS package that can be deployed to a VM on another domain (same computer) that has SSIS on it. The package that I have created will transfer data if I simply run the data flow from SSDT on the source computer, but when I try to deploy and execute it, it appears to have 2 errors. The first being that it cannot open the datafile "C:\SSIS\Product Data.txt". The second being that the Flat Files Source 1 failed the pre-execute phase. I think that the second error is caused from the first. Does anyone know how to create a package that can transfer data to another computer without the flat file source?
Thanks in advance!
C:\SSIS.... will refer to the local C drive of the computer that is executing the package. So if you have it on the VM it would be at the \VM\C$. Typically it means 1 of 2 things.
1) The file path is not correct and you are not referencing where the file actually is.
2) the user you are executing the package as does not have permission to that file.
So where is the file is it on the C drive of the machine you are executing the SSIS package on? The answer to that wasn't clear in your question.
Second how is the file being executed? manual execution such as DTS_Exec? SQL Agent? T-SQL? If manual then the user logged in executing the task must have permission, if SQL Agent then the sql agent service account and possible the sql server service account have to have permission to the file, and T-sql sql server service account needs to have permission.
When it is local file path then a local user or domain user will work for the service accounts. If network path then the local user used for service account won't work and you will need to setup a way to run as a different credential.
I have an SSIS package I can import into Integration Services on my server and run with no problems. All it does is copy files from a directory on the network to the server it is running on.
When I execute the SQL Agent Job it says the job ran successfully but no files are copied. I verify there are files in the source location and the destination path exists. I am also using absolute paths (no mapped drives).
Why doesn't it copy any files when I run it as a SQL Agent Job?
FYI - the source directory is actually on a UNIX box and to map a drive to that location you have to enter a user/password combination.
I have a feeling that the SQL Agent Job runs as NT SERVICE\SQLSERVERAGENT, which is not the user that has permission to the UNIX box. Is there a way to run the SQL job as a specific user?
Thanks in advance.
You need to create a Credential, a SQL Agent Proxy, and then assign the proxy account to the SQL Agent job step. Proxy accounts are specific to each subsystem (e.g Powershell, CmdExec, SSIS, etc.)
-- creating credential
USE [master]
GO
CREATE CREDENTIAL [Superuser] WITH IDENTITY = N'DOMAIN\account', SECRET = N'mypassword'
GO
-- creating proxy for CmdExec subsystem, adding principal
USE [msdb]
GO
EXEC msdb.dbo.sp_add_proxy #proxy_name=N'My custom proxy',#credential_name=N'Superuser',
#enabled=1
GO
EXEC msdb.dbo.sp_grant_proxy_to_subsystem #proxy_name=N'My custom proxy', #subsystem_id=3
GO
EXEC msdb.dbo.sp_grant_login_to_proxy #proxy_name=N'My custom proxy', #fixed_server_role=N'sysadmin'
GO
-- assigning job step to run as a given proxy user
USE [msdb]
GO
EXEC msdb.dbo.sp_update_jobstep #job_id=N'0df2dac2-4754-46cd-b0bf-05ef65e1f87e', #step_id=1 , #subsystem=N'CmdExec',
#proxy_name=N'My custom proxy'
GO
I have an SSIS package that takes data from a MySQL database and puts it in to a SQL Server table. The connection to MySQL is ADO.net. The package runs fine in BIDS.
I would like to deploy the package to be run as a Job on SQL Server 2008. The MySQL connection requires sensitive data to be either stored within the package or held in some external configuration source. If it is stored within the package it will either by encrypted with a key specific to my windows user profile or must be protected via a password.
I have tried three methods of setting up a SQL Server Agent job to execute this pacakge, and all fail:
Using a Password
I set the ProtectionLevel of the package to EncryptSensitiveWithPassword and supply a password for the package. I then save a copy of the package to the msdb. I can then connect to SSIS and run the package, at which point I am prompted for a password.
When I try to schedule this as a job in SQL Server I am prompted to enter the password by clicking on the Configurations tab of the Job Step Properties and I can see that the /DECRYPT switch has been added to the Command Line tab. The Run As property is set to the SQL Server Agent Service Account, which is mapped to a database login that has sysadmin server role. When I attempt to start this job I get the following error:
Executed as user: DOMAIN\UserROLE. Microsoft (R) SQL Server Execute Package Utility Version 10.0.5500.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 12:31:30 Error: 2012-07-03 12:31:31.20 Code: 0xC00291EC Source: Get Data Execute SQL Task Description: Failed to acquire connection "DATA_SOURCE". Connection may not be configured correctly or you may not have the right permissions on this connection. End Error DTExec: The package execution returned DTSER_FAILURE
It seems that using this method the package password itself is not stored anywhere for the job to access it.
Using an XML configuration file
I then created a copy of the package and set the ProtectionLevel to DontSaveSensitive and I set up a package configuration to store the MySQL credentials in an XML file. I then save this to the msdb and then when I run the package from
Integration Services I can provide a path to the config file, and all is well. However, once again when I set up a job for the package I point to a configuration file on the server but the job fails with the same error. I am wondering whether this is because the SQL Server Agent does not have an associated windows account that would allow it to read from the XML file stored in the file system.
Using a SQL Server table configuration
This time I created a copy of the package and set the ProtectionLevel to ServerStorage. I then created a [SSIS Configurations] table in the target SQL Server database. I modified the entries in this table to contain the password for the MySQL data source. Again, the package runs successfully from Integration Services, but fails with the same error as previously when run from a job. I have checked that the SQL Server Agent is able to read from the [SSIS Configurations] table ok - I set up a standalone job to test this.
Does anyone have any suggestions about what else I should do here?
I am thinking of giving up on SQL Server Agent Jobs for this and going back to having the package scheduled simply by the windows scheduler but thought before throwing in the towel I would try here first.
I am using the method of encrypting the password by setting EncryptSensitiveWithPassword as you discribed above and don't see anything you do wrong. Remember to use option keep protection level of the original package when importing the package with integration services, but it looks like you're doing that, too.
Try setting the role SQLAgentOperatorRole to your SQL Server Agent Service Account, you didn't mention that and i am not sure if you did. This could possibly solve your permission problems. (liked to answer by commenting this, but i lack of permissions here, too :)
I have an SSIS package which contains an Analysis Services Processing Task.
This package is kicked off by a SQL Server Job in SQL Server 2008 R2.
If I run this job myself or process the cube manually everything is fine.
However if I schedule the job and let the SQL server agent run it then the Analysis Services Processing task fails stating Errors in the OLAP storage engine and that an error occurred while processing the one of the measure groups.
Has anyone else every seen anything like this?
The SQL Server Agent service account may not have sufficient permissions. You can validate this by doing any of the following:
Add the service account to the Administrators group on the analysis services server to validate this issue. Let the job run as scheduled.
Create a proxy that runs under your credentials and set the job to execute under the proxy. Let the job run as scheduled.
Change the SQL Server Agent to use your credentials. Let the job run as scheduled.
If the job completes successfully after making any of the above changes, then you have a permission issue that you need to resolve.
So after months of looking at this I finally realised the answer; of course it's a simple one.
The SSIS job I had created was processing the Cube only, while every time I processed manually in management studio I was processing the whole SSAS database.
I've now changed the SSIS package to process the whole database and everything seems to be working correctly.
when This Error Generate :
reporting services catalog database file existence failed sql server 2008 r2
================================================================================
This issue occurs because the databases for the SQL Server 2008 Reporting Services instance that you want to install already exist on the computer with following path.
C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA
Manually Remove .MDF and .LDF files of Report from above path and Re-run Setup.
In my case I found the solution in other way. First of all I login into analysus services using SQL management studio.Second of all I searched into databases folder the name of my project, after I open that and double clic in Roles folder, clic in new role, in this window I selected Membership in the left pane, clic in add button and search the NT AUTHORITY\Service, clic in Ok button and finally restart Sql analysis services. I tried to run my job and It works.