I have a page on the server and i tried to run it like this article:
http://www.eggheadcafe.com/articles/20010328.asp
then I get an error:
Executed as user: NT AUTHORITY\NETWORK SERVICE. The step did not
generate any output. The step failed.
When I try to edit the script I get another error:
Creating an instance of the COM component with CLSID
{AA40D1D6-CAEF-4A56-B9BB-D0D3DC976BA2} from the IClassFactory failed
due to the following error: c001f011.
(Microsoft.SqlServer.ManagedDTS)
When I run the asp page manually it works fine! do you know what can be wrong?
I would apply the most recent service pack for SQL Server both to your server and to the workstation(s) where you use Management Studio. The error you mentioned has been fixed: http://connect.microsoft.com/SQLServer/feedback/details/557402/ssms-can-no-longer-create-or-edit-job-steps
This will fix the problem when you edit the job step in Management Studio. There are some other workarounds (e.g. re-register some DLL, or restart Management Studio), but those are only temporary. You can also disable UAC, but you may have that feature enabled for a reason. The real fix is to apply service packs / cumulative updates to fix the underlying code.
As for the error message from the job, there could be a number of things going on. Who is the owner of the job? Who is the user executing the VBScript? What exactly is the job doing?
Related
I am able to get into SharePoint site using browser but not able to connect it using SSIS ODATA Connector. I have admin rights in that site. We have multiple imports successfully running using same SharePoint Server right now. Using SSDT2012. I tried another site successfully to confirm I don't have issue with SSDT. Any idea what I am missing.
Error msg:
TITLE: OData Connection Manager Editor
Test connection failed
ADDITIONAL INFORMATION:
The remote server returned an error: (401) Unauthorized. (System)
The logon attempt failed (System)
BUTTONS:
OK
What is the Service Document Location URL, you are giving in your case? Here is mine which works well.
Are you using basic authentication or Windows authentication?
If the former, double and triple-check that your userid and password are correct, and that the credentials have the proper access.
If the latter, check to see what user the package is running as. Also, I've found that when using Windows Authentication, you have to go back and double check what the Basic Authentication settings are, and zero them out before going back to Windows Authentication. It sounds crazy, but sometimes it works.
I'm working on integrating a report into a browser, and I get this error:
An error has occurred during report processing. (rsProcessingAborted)
Cannot create a connection to data source 'dsFederatedSample_SurveyLevel_STG'. (rsErrorOpeningConnection)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
Does this have to do with SQL vs Windows authentication?
First thing I would try is to get a bit more information on the error - that's a pretty generic message.
You could enable remote errors as per the error message and replicate the error for more information.
Or check the Report Server error logs to see what error was logged.
%programfiles%\Microsoft SQL Server\<SQL Server Instance>\Reporting Services\LogFiles\
The next step would be to connect as the Data Source user to the database, run any code/stored procedures that the report is using with the same parameters you're using when running the report, and see if any errors occur. Make sure the account you are using has permission and that you have entered the name and password correctly in the Data Source.
In SQL Server 2008 in addition to the above two options you have a third option to make this setting through SQL Server Management Studio.
1.Start Management Studio and connect to Report Server Instance (make sure you select 'Reporting Services' server type).
2.Right click on the ReportServer and Select Properties
3.Click Advanced
4.In EnableRemoteErrors, select True.
5.Click OK.
I had the same issue "Cannot create a connection to data source...Login failed for user.." on Windows 8.1, SQL Server 2014 Developer Edition and Visual Studio 2013 Pro. All solutions offered above by other Stackoverflow Community members did not work for me.
So, I did the next steps (running all Windows applications as Administrator):
VS2013 SSRS: I converted my Data Source to Shared Data Source (.rds) with Windows Authentication (Integrated Security) on the Right Pane "Solution Explorer".
Original (non-shared) Data Source (on the Left Pane "Report Data") got "Don't Use Credentials".
On the Project Properties, I set for "Deployment" "Overwrite DataSources" to "True" and redeployed the Project.
After that, I could run my report without further requirements to enter Credentials. All Shared DataSources were deployed in a separate Directory "DataSources".
In my case, this was due to using Integrated Windows Authentication in my data sources while developing reports locally, however once they made it to the report manager, the authentication was broke because the site wasn't properly passing along my credentials.
The simple fix is to hardcode a username/password into your datasource.
The harder fix is to properly impersonate/delegate your windows credentials through the report manager, to the underlying datasource.
The issue is because your data source is not setup properly, to do that please verify your data source connection, in order to do that first navigate to Report Service Configuration Manager through
clicking on the start -> Start All -> Microsoft SQL Server ->Configuration Tool -> “Report Service Configuration Manager”
The open Report Manager URL and then navigate to the Data Source folder, see in the picture below
Then Create a Data Source or configure the one that is already there by right click on your database source and select "Manage" as is shown below
Now on the properties tab, on your left menu, fill out the data source with your connection string and username and password, after that click on test connection, and if the connection was successful, then click "Apply"
Navigate to the folder that contains your report in this case "SurveyLevelReport"
And Finally set your Report to the Data Source that you set up previously, and click Apply
if you use null values in your stored procedure, you will need to set the parameters to accept null values. That worked for me.
In my case I had in one report many different datasets to DB and Analysis Services Cube. Looks like that datasets blocked each other and generated such error.
For me helped option "Use single transaction when processing the queries" in the CUBE datasource properties
I had a similar problem, and being the newbie that I am it took me a while to figure out but I learned the user must have a login in SSMS. I created the logins with the following parameters:
Under Server Roles - check sysadmin
Under User Mapping - I selected the database and the report server. For each I checked datareader and datawriter
Under Securables - I checked anything that would allow the user to connect to the database and view anything
I also found that one of the existing logins had denydatareader and denydatawriter checked. Once I removed these it worked.
I'm not saying this is the best way to do it, just what worked for me. Hope this helps
More information will be useful.
When I was faced with the same error message all I had to do was to correctly configure the credentials page of the DataSource(I am using Report Builder 3). if you chose the default, the report would work fine in Report Builder but would fail on the Report Server.
You may review more details of this fix here:
https://hodentekmsss.blogspot.com/2017/05/fix-for-rserroropeningconnection-in.html
I had the exact same issue.
The cause could be different but in my case, after trying several different things like changing the connection string on the Data Source setup, I found that this was the infamous 'double hop' issue (more info here).
To solve the problem, the following two options are available (as per one of the responses from the hyperlink):
Change the Report Server service to run under a domain user account, and register a SPN for the account.
Map Built-in accounts HTTP SPN to a Host SPN.
Using option 1, you need to select 'Windows' credentials instead of database credentials to overcome the double hop that happens while authentication.
I'm working on integrating a report into a browser, and I get this error:
An error has occurred during report processing. (rsProcessingAborted)
Cannot create a connection to data source 'dsFederatedSample_SurveyLevel_STG'. (rsErrorOpeningConnection)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
Does this have to do with SQL vs Windows authentication?
First thing I would try is to get a bit more information on the error - that's a pretty generic message.
You could enable remote errors as per the error message and replicate the error for more information.
Or check the Report Server error logs to see what error was logged.
%programfiles%\Microsoft SQL Server\<SQL Server Instance>\Reporting Services\LogFiles\
The next step would be to connect as the Data Source user to the database, run any code/stored procedures that the report is using with the same parameters you're using when running the report, and see if any errors occur. Make sure the account you are using has permission and that you have entered the name and password correctly in the Data Source.
In SQL Server 2008 in addition to the above two options you have a third option to make this setting through SQL Server Management Studio.
1.Start Management Studio and connect to Report Server Instance (make sure you select 'Reporting Services' server type).
2.Right click on the ReportServer and Select Properties
3.Click Advanced
4.In EnableRemoteErrors, select True.
5.Click OK.
I had the same issue "Cannot create a connection to data source...Login failed for user.." on Windows 8.1, SQL Server 2014 Developer Edition and Visual Studio 2013 Pro. All solutions offered above by other Stackoverflow Community members did not work for me.
So, I did the next steps (running all Windows applications as Administrator):
VS2013 SSRS: I converted my Data Source to Shared Data Source (.rds) with Windows Authentication (Integrated Security) on the Right Pane "Solution Explorer".
Original (non-shared) Data Source (on the Left Pane "Report Data") got "Don't Use Credentials".
On the Project Properties, I set for "Deployment" "Overwrite DataSources" to "True" and redeployed the Project.
After that, I could run my report without further requirements to enter Credentials. All Shared DataSources were deployed in a separate Directory "DataSources".
In my case, this was due to using Integrated Windows Authentication in my data sources while developing reports locally, however once they made it to the report manager, the authentication was broke because the site wasn't properly passing along my credentials.
The simple fix is to hardcode a username/password into your datasource.
The harder fix is to properly impersonate/delegate your windows credentials through the report manager, to the underlying datasource.
The issue is because your data source is not setup properly, to do that please verify your data source connection, in order to do that first navigate to Report Service Configuration Manager through
clicking on the start -> Start All -> Microsoft SQL Server ->Configuration Tool -> “Report Service Configuration Manager”
The open Report Manager URL and then navigate to the Data Source folder, see in the picture below
Then Create a Data Source or configure the one that is already there by right click on your database source and select "Manage" as is shown below
Now on the properties tab, on your left menu, fill out the data source with your connection string and username and password, after that click on test connection, and if the connection was successful, then click "Apply"
Navigate to the folder that contains your report in this case "SurveyLevelReport"
And Finally set your Report to the Data Source that you set up previously, and click Apply
if you use null values in your stored procedure, you will need to set the parameters to accept null values. That worked for me.
In my case I had in one report many different datasets to DB and Analysis Services Cube. Looks like that datasets blocked each other and generated such error.
For me helped option "Use single transaction when processing the queries" in the CUBE datasource properties
I had a similar problem, and being the newbie that I am it took me a while to figure out but I learned the user must have a login in SSMS. I created the logins with the following parameters:
Under Server Roles - check sysadmin
Under User Mapping - I selected the database and the report server. For each I checked datareader and datawriter
Under Securables - I checked anything that would allow the user to connect to the database and view anything
I also found that one of the existing logins had denydatareader and denydatawriter checked. Once I removed these it worked.
I'm not saying this is the best way to do it, just what worked for me. Hope this helps
More information will be useful.
When I was faced with the same error message all I had to do was to correctly configure the credentials page of the DataSource(I am using Report Builder 3). if you chose the default, the report would work fine in Report Builder but would fail on the Report Server.
You may review more details of this fix here:
https://hodentekmsss.blogspot.com/2017/05/fix-for-rserroropeningconnection-in.html
I had the exact same issue.
The cause could be different but in my case, after trying several different things like changing the connection string on the Data Source setup, I found that this was the infamous 'double hop' issue (more info here).
To solve the problem, the following two options are available (as per one of the responses from the hyperlink):
Change the Report Server service to run under a domain user account, and register a SPN for the account.
Map Built-in accounts HTTP SPN to a Host SPN.
Using option 1, you need to select 'Windows' credentials instead of database credentials to overcome the double hop that happens while authentication.
I'm trying to use MS Reporting Services. So far I have been able to create a simple report, using the AdventureWorks database.
Next step I wanted to take was to deploy my report. This is what I did:
In the Business Intelligence editor I right-clicked on the project name and clicked properties
I added a Start Item and I set the TargetServerURL to the URL that was displayed in the Reporting Services Configuration Manager. The URL is: http://ADMIN-PC:80/ReportServer
After that I clicked "OK" to go out of the Properties window. Then I hit Build Report Project1 in the Build menu.
After it tries to build it gives me the following error:
The specified report server URL: "http://admin-pc/ReportServer" could
not be found. Verify the syntax of the URL and that the report server
exists.
I'm sure the URL is correct. Or at least, that is what the Reporting Services Configuration Manager says.
So I have no clue what to check next in order to fix this problem. Anyone any idea what to do?
It's always tough to try and troubleshoot these general "it's not working" errors, but here's a rough idea of what I'd try looking at:
Is the service running? If you can connect through Reporting Services Configuration Manager then the answer is probably yes, but it's always the first thing to check!
Are the URLs correct? You may need to check you're using the correct URLs - these can be confirmed through Reporting Services Configuration Manager; by default Named Instances will have URLs like http://admin-pc/ReportServer_InstanceName and http://admin-pc/Reports_InstanceName.
Can I connect out of BIDS? What happens when you connect to http://admin-pc/ReportServer through Internet Explorer? What about http://admin-pc/Reports?
Are there permission issues? By default the only users that can access SSRS are those in the BUILTIN\Administrators group. Is your user in this group?
Is UAC mucking me up? As above, only Administrators will have default access, but if UAC is enabled you still won't connect as an admin even if you're in this group. Try running BIDS or Internet Explorer with Run As Administrator and see if it makes any difference.
Is the URL being registered successfully? The URLs won't work if the port is already in use, but Reporting Services Configuration Manager will quite happily allow you to set this without an error even if the port's in use; it's especially when using port 80.
Check the log file at Program Files\Microsoft SQL Server\<SSRSInstance>\Reporting Services\LogFiles; this will have an error logged if it can't register the URL on the port specified. If you see an error here try a different port.
Any other errors in the log? Failing this, check the log for any more errors.
Not much to go on, I admit, but maybe there's something you haven't looked at here. I'd saying stepping through these checks has solved 99% of the errors that I've seen in the past.
I've deployed a SSIS package to my SQL server.
I can run the package fine by connecting to Integration Services in SSMS and right clicking on it and choosing "Run Package"
However, if I schedule the package, it fails.
It tells me to check the logs for information on why, but there is nothing in there...
Any ideas?
(this is my first SSIS package by the way)
I would guess your package is doing something the SQl Server agent deosn't have the rights to do. Often it turns out that the location of file to be imported or the location where the file exported are in directories that are not open to the account that runs the SQL Server Agent.
I also agree woth Raj who said you really need to implement logging. You can;t expect to know why something fails six months down the road if you aren't recording the details of waht is happening with the package. SSIS pacakages can be hard to debug anyway, so you need those logs to know where to start looking.
You have to implement logging to get the details of the error.
In SQL Server Agent, create a new job, configure it to execute the package and under the logging tab, start logging.
Then run the package and you can read the log in the job history.
When you said you have scheduled a job, I assume you used SQL agent. In that case you can right click job and click View History and you can see the error related to job not to the package. For detail error you need to configure logging.