I developed an SSIS package on my database server (ServerDB) to execute SSRS reports on another server (ServerRPT).
When I run the SSIS package using MS VS 2008 on ServerDB, the reports can be generated.
Then, I try to schedule the package on my database using SQL Server Agent, the package failed to produce the reports. File name has been created on the server but zero file size. So, the package execution is fine and problem potentially lies on the Reporting Server access.
Reporting Server (ServerRpt) has a Windows Service Account.
Database Server (ServerDB) jobs executed using SQL Server Agent Account.
Is there anything I miss out or accounts that need to be created ?
Suspect it could be permission issue on ServerRpt.
Hope you can shed some lights.
Thanks ....
Related
I have a OLEDB task that connects to ms-access database on local file system and dumps data into sql database.
Access db connection string is: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.16.0;
The SSIS package runs OK in visual studio. Access 2016 32-bit runtime is installed on this computer.
After deployment to SSIS catalog, right click and execute works OK. Access 2016 64-bit runtime is installed on this computer.
When this package is scheduled to run via SQL Agent job, using proxy/credential [domain user - example: domainname\user1] (having read permission on the access db file), then the job fails. The SSIS execution report shows error as: Unexpected Termination. There is no further information.
Suppose if I add the proxy credential (domainname\user1) to the local administrators group (in computer management) then the SQL Job runs OK. What could be the solution to this so I can give only the minimum required permissions?
The error is very difficult to debug as it doesn't occur when running via visual studio. Even when deployed to the SQL server and run from the SSIS catalog, the execution works OK. The error occurs only when the package is run via SQL server agent job (via credential/proxy) - the SSIS execution report doesn't show any helpful messages; and surprisingly the error gets resolved when the credential is added as local administrator on the computer - which is a bad practice.
The solution is analyse what kind of ms access file you are using and appropriately use the correct access runtime version (2013 vs 2016) and the correct provider value in the connection string.
Access runtime:
In my case, I uninstalled Access 2016 64-bit runtime and installed Access 2013 64-bit runtime.
Provider version:
I changed the provider version from 16.0 to 15.0, as shown below-
Before: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.16.0;
After: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.15.0;
Note:
There is no need to add the user to the local administrator group.
There is no need to login to the computer using that account.
Only read permission (under windows folder security) is sufficient assuming the SSIS packge will only read the ms access database.
It's hard to debug this only with the information provided, but in general:
The user running the job requires at least write and delete access on the underlying folder in which the Access database resides. This is required to generate a lockfile for the database.
If this is undesirable because the job may be modified by a malicious user, I've seen deployments where a copy is made in a temporary folder with write access and a size quota, and that temporary folder is removed as soon as the job finishes, regardless of if the job succeeded.
I am getting the following error:
The operation cannot be started by an account that uses SQL Server Authentication. Start the operation with an account that uses Windows Authentication
I have a ssrs report which uses a dataset derived from a stored procedure. The stored procedure first creates an execution and executes a ssis package before drawing the data. In visual studio I can preview the report fine. The data source uses integrated security (though I wish I could pass a sql server account). When I upload the report to SSRS it gives me the error about using an account with windows auth. I checked the datasource on the server and it is set to use windows auth. I'm not sure what I am doing wrong or how to fix this.
my sql server is 2012 r2 (ssrs is 2008)
The issue is that you cannot execute SSIS packages which are stored on your SSISDB Catalog using a SQL Server account.
This is why changing the user which is attempting to start the SSIS package to a 'Windows Authentication user' works.
A similar issue can be found here;
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/bbd2b556-8f68-4e04-94d1-754127886361/unable-to-execute-ssis-package-from-sql-server-login?forum=sqlintegrationservices
schedule the SSIS package as a job with windows authentication, then call the job itself using
USE msdb;
GO
EXEC dbo.sp_start_job N'NAME OF JOB';
GO
works for me
Apparently putting a windows login in the data source worked, couldn't get it to go in visual studio but updating the datasource on ssrs did the trick.
Trusted_Connection = False;
Password = ***;
User ID = ***;
Data Source = localhost;
Initial Catalog = master;
Integrated Security = SSPI;
This connection string worked for me!
Integrated Security = SSPI;
Ignores UserId and Passwords and uses Windows Authentification :D
I am trying to deply SSIS Package (ispac file) created in SQL 2012 Data Tools using SQL Server 2014
I have followed following steps
Opened SQL 2014
Connected to Datase Server (SQL Server 2012)
Created a folder under Integration Services Catalog/SSISDB
Double clicked on my ispac file and selected source as Ispac file and Destination as the folder created in step 2
The package was deployed successfully.
Configured the parameters properly
However when I Validated or tried to execute the package it gave me following errors.
When I tried to deploy it on SQL 2012 using SQL 2012 client instead of MS SQL 2014 it worked fine. I tried it by remotely logging into database server.
Is there any solution for it?
Do I have to login to server and perform the deployment. Can't I just do it from my Local machine?
Your log definitely shows that packages were upgraded to SSIS 2014 format - see message with PackageFormatVersion 8. When you deploy project with SSIS Deployment Wizard, which is invoked from SQL 2014 SSMS, the Project is converted implicitly. Recommendation - install SSMS from SQL 2012 and deploy from it. You might do it locally, not necessarily logging on to the server.
I have TFS2012 with MSSQL on my single server.
I am getting the following error in Microsoft Excel to generating reports(graphs) for TFS Queries (from project admin account, connection by the network).
TF208093: You cannot use work item queries to generate reports in Excel on this server because it is not configured for reporting
At the same time there is NO error when i connect with windows server admin credentionals
any ideas?
Try use http://tfsadmin.codeplex.com/ to check the users permissions in SSRS.
Hi
I am trying to build an SSIS package to import text files to SQL data tables and then move the text files to a 'processed' file.
I can get the package to run successfully on my workstation in Visual Studio 2005 (although I got 'access denied' on the 'move' operation but I will worry about that later).
However, when I deploy to the SQL server, and execute the package on the server, I get DTS_E_PRODUCTLEVELTOLOW error on the import to SQL stage. I have checked the SSIS service is running on the server which it is.
The data upload is very simple - just the first column from the text file plus the file name in two columns, so none of the 'smart' stuff that might not be installed.
Can anyone help?
Thanks!
http://msdn.microsoft.com/en-us/library/aa337371.aspx
says
Possible Causes
This message might appear because of one of the following problems:
You have installed BI Development Studio but you have not installed Integration Services. Running packages outside Business Intelligence Development Studio requires the installation of Integration Services.
Your package may be attempting to use advanced components for Analysis Services, data mining, or text mining that are available only in SQL Server Enterprise.
In the unlikely case you are using SQL Server 2005 without any service packs, there was a problem with running the Import-/Export Data Wizard. This problem was solved beginning with SP1.
A great collection of tips are in this blog post:
http://blogs.msdn.com/b/michen/archive/2006/11/11/ssis-product-level-is-insufficient.aspx
Update:
To find out, what SQL Server Version you are running, execute the following query on your server:
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
The second column of the result tells you the service pack level.