We have acquired an application that was written approximately 2003. Part of the app uses SQL Server Reporting Services to generate PDFs of reports. Basically within the app a user clicks a button, modifies parameters (start/end date) and a report is passed back (i think) in PDF format so that it can be printed. Great. Works fine in SQL 2005.
However, SQL 2008 is another beast entirely. I can run the same report from the web interface (http://127.0.0.1/reports/...). But the URL doesn't work. I dug around and found that the app is sending a call to 127.0.0.1/reportserver/reportservice.asmx. Now it returns an empty string instead of the XML document.
Supposedly there is a 2005 compatible version called reportserver/reportexecution2005.asmx but that generates a whacky SOAP error. "System.Web.Services.Protocols.SoapException: Server did not recognize the value of HTTP Header SOAPAction: http://schemas.microsoft.com/sqlserver/2003/12/reportingservices/Render. at System.Web.Services.Protocols.Soap11ServerProtocolHelper.RouterRequest() ....
I notice now when I try to use internet explorer and browse to 127.0.0.1/reportserver/reportservice.asmx i get a login prompt, whereas that was not the case with SSRS 2005. I also notice that if I browse to reportserver/reportexecution2005.asmx it returns a XML page which seems mostly similar to what was returned in SSRS 2005.
So obviously I am missing something. I think since the app was created a while ago I should be using the SQL2000 version which is 127.0.0.1/reportserver/reportservice.asmx. But I think now there is an authentication error.
Anyway. I'm clueless. Anyone have any thoughts? Thanks.
We don't have the source code to the app, but I can modify the connection parameters, like I can ask it to query for ReportServiceXXX.asmx instead of ReportService.asmx
You are very close to seeing the problem. If you look closely at the XML from ReportExecution2005.asmx you will see that it is in Soap12. Your error message shows that a call was made using method System.Web.Services.Protocols.Soap11ServerProtocolHelper.RouterRequest, which is sending a Soap11 message. I am having the same problem, but have not solved it yet.
My two options are to either add a binding to SQL 2008 report service to accept Soap11 or modify my code to send Soap12. I am hoping for a simple config change in SQL server, but have not found it yet.
Related
I have an SSRS report that works perfectly in Visual Studio 2017.
But when I deploy it, the deployed report comes back with all the data, ignoring the filters in the WHERE clause. I know it's this because when I remove the WHERE clause from my Visual Studio report, the data matches the deployed report.
This report pings off a shared data source; the dataset is not a shared.
Even a simple WHERE tbl.flag = 'Y' does not seem to do anything to the deployed report.
Why is SSRS not recognizing the entire SQL?
Not really an expert in SSRS, I just make them based off some YT tutorials and deploy them to the link that was given to me, so any advice or links for research are appreciated.
Check the server setting in the report project properties in Visual Studio.
If they look OK then delete the server copy of the report and redeploy.
If the report does not reappear then that proves that the report is either
a. not being deployed (you should see an error in the visual studio output window), or
b. it's being deployed to where you think it should be.
From the web portal you can search for a report by name and it will search all folders on the server so if it did deploy OK, you could find it that way.
I have discovered the issues was some inline comments I had in the SQL. I had some comments above the WHERE clause using dashes, --, explaining the filter. Once I removed it, the report executed correctly.
I was also able to change the comment style to the /* <my comment> */ and it executed correctly. It seems that other style of comments with dashes made the server think everything afterwards was a comment, and therefore not executed.
I have a problem..
I work with ASP.NET and After I add a data (Arabic language) to my form via the browser it added to the SQL Server Management Studio like this (???????) even when I retrieve the data entered by the browser, Although there is no problem when I add my Arabic data via SQL Server Management Studio direct.
(there is no problem with English data)
Somewhere along the way your changing the charactertype to something else, that is probably Standart ascii.
It is impossible to know where exactly since we don't have hany information about that, but I would guess that in your Backend things are messed up, try commenting out your code and just echoing the values to see if they are already wrong at that stage.
Maybe change the Stringtype to utf-16
That should support any chars you throw at it
I have a lightswitch project in visual studio 2013, using vb.net. I would like the user to be able to click a button and have lightswitch find an excel file, and upload that file to a sql table according to a pre-determined column mapping.
My preference was to use the Office Integration extension for visual studio, which I got working with VS 2013 by downloading it from this link: http://www.ge.tt/71iuRQv/v/0
However, the documentation and examples for office integration seem to be very heavy on getting an excel spreadsheet into a display in the lightswitch web client, rather than into the sql data table, which is where I need it. Here are the examples I've been following:
http://blogs.msdn.com/b/bethmassi/archive/2012/07/18/new-and-improved-office-integration-pack-extension-for-lightswitch.aspx
Alternatively, I have an existing stored procedure, and I can request that the server call this stored proc by sending a web API extension from the client to the server. I have this working already for other stored procs, according to examples from Beth Masi and Paul van Bladel. (Stackoverflow won't let me post the links...)
The undesirable part of this approach is that the stored proc is old, and messy.
I've searched and searched, but have yet to find anyone approach this problem for VS 2013 with lightswitch. Any useful advice?
I've used the method detailed by Matt Sampson to store word files and it works very well. Since it just stores the raw binary it should handle Excel files just as well.
If you're creating the table in LightSwitch, use the Binary Type. If you use SQL create scripts use varbinary(MAX).
You need to create a custom Silverlight dialog box to gain access to the OpenFileDialog object. Then open the file in as a FileStream.
Finally, you need to add a handler for the closed method of the control and then show the control to the user. Most likely done in a button. This needs to be done on the main dispatcher.
The code examples are in C# but I just used one of the many available translators out on the web and copy/pasted the VB.NET code.
Another option might be to consider shelling out to the DTSEXEC run-time to execute an SSIS package to perform the upload - especially if the target Excel spreadsheets have predefined layouts and content data types.
Even simpler, you might be able to use the SQL Server BULK INSERT command to get the job done - although that would require a SQL Client connection to your database.
HTH
please give me some advice. I have to send email using SQL database mail. In my email, I have to create links that a user can click to go to a product page on my site. However, I need to encrypt the ID of the product and once the product page load, the querystring of the product ID will be decrypted.
How can I get the encryption algorithm which I created in web site class into SQL? I believe the decryption and encryption algorithm must be the same, so that my page can decrypt correctly when the user click on the link in their email. The encryption class I use is something similar to this link: http://www.codeproject.com/Articles/33350/Encrypting-Query-Strings
Thanks a lot for your help.
PS: I also posted this question on asp.net forum.
You can run CLR (ie .NET) code within SQL Server. There are several steps involved, but it starts with creating an "SQL Server" project within Visual Studio, writing the code, and deploying it to your SQL Server. You also have to enable CLR functions within SQL Server using sp_configure.
See here (MSDN) for detailed instructions: How to: Create and Run a CLR SQL Server User-Defined Function .
After doing quite some research, I can confirm that CLR is the way to go. As suggested, I used user defined function CLR. First I need to create CLR project in visual studio. Here is a good starting point to understand how it works:
http://blog.sqlauthority.com/2008/10/19/sql-server-introduction-to-clr-simple-example-of-clr-stored-procedure/
Then instead of adding a CLR stored procedure I move to User defined function. Add an encryption class and called the class in the user defined function. Build and Deploy. That's it.
Here is another useful links:
http://channel9.msdn.com/Learn/Courses/SQL2008R2TrainingKit/CLR/CLRIntegrationLab/Exercise-1-Creating-User-Defined-Functions-Using-SQL-CLR
Thanks dbaseman for pointing that out.
We have one report that when run throws an error stating "Database login failed". I have 20+ reports configured the same way that execute without any problems. In the Crystal Reports Designer, I verified the database and everything is good. The sql queries used to generate the report look good.
The reports are run from an ASP.NET application. We're not using a report server. We're using the 13.x runtime on the server. Reports are defined in CR Designer and passed parameters from the ASP.NET application.
Can Crystal store a username and password in the report file? How do I clear any saved values? Any other ideas? I'm a bit lost here since everything else is working just fine.
Yes. Crystal can store authentication/connection info in the .rpt file. You can override this with your ReportSource definition by setting parameters.
It most definitely does NOT store account/password in the RPT file.
You will need to explicitly set the authentication credentials.
It does not store the password. It does store the ID most of the time. The reason some reports work sometimes has to do with if Windows authentication indicates you have access to the data.
The safest most consistent way to run reports is to use the ID/password evertime, although in some cases, if it's expecting Windows authentication only, putting the ID/password will cause it to fail.