Find All WebI Reports that Use Free-hand SQL - business-objects

We are on 4.1 SP06 Patch 4.
Is there a way to find all Web Intelligence reports in which free-hand SQL is being used?
Thanks

I found the SI_FHSQL_RELATIONAL_CONNECTION property in QueryBuilder indicates the presence of free-hand SQL provided its SI_TOTAL child property is greater than 0. I am only concerned with Web Intelligence reports so I can filter on that too...
select *
from CI_INFOOBJECTS
where SI_KIND = 'Webi'
and SI_FHSQL_RELATIONAL_CONNECTION.SI_TOTAL > 0
One exception seems to be that if a report had free-hand SQL at some point, but then that query gets deleted this property doesn't get reset.

Related

How to get filtered view to work in an entity SSRS report

I am trying to build an SSRS report to be put in Dynamics CRM and run from a record in the Account entity. My initial query to pull the data is pretty simple, but the functionality of the SSRS report and filtered view aren't working as expected. I'm using the custom report data source from the CRM data source folder, so I know that's not the issue (see here).
Here's my query (which is very basic):
SELECT Name
,Address1_Line1
,Address1_Line2
,Address1_City
,Address1_StateOrProvince
,Address1_PostalCode
,kore_salespersonidName
,kore_coordinatoridName
,client_FulfillmentContactName
,OpenDeals
,OpenRevenue
,client_ActivationBalance
,client_SponsorLevel
,client_PreviousSeasonSpend
,client_CurrentSeasonSpend
,Description
,kore_industryidName
FROM FilteredAccount AS CRMAF_FilteredAccount
I've also tried to use a another one as a filter for the report using a where clause on the end of the first query, but that just returns a random list of results as well.
Here's the one I've used for the filter:
SELECT CRMAF_FilteredAccount.AccountId
,CRMAF_FilteredAccount.Name
FROM FilteredAccount as CRMAF_FilteredAccount
WHERE CRMAF_FilteredAccount.statecode = 0
This is a similar issue I have, but no resolution: Similar issue.
Any help is appreciated.
Looks like my issue was just a bug with CRM. If you originally upload the report and don't specify in the "Display In" that it needs to be in "Forms for related record types" then it doesn't look like it'll change even if you change that value and the report will always run for all records. I found this link where it suggested that I delete the report and reupload it, which solved the issue.

SSS Report Builder 3.0 Query Parameter - Report Preview

This is a bit strange to me. I am using a SSRS Report Builder 3.0 for creating a report. I have two options: 1. Use a filter linked with report parameter OR 2. Use a query parameter linked with report parameter.
In the first case, the report preview works perfect. I am using a simple query for filter with parameter (#parameter_a) applied on ID column:
Select ID, Name from tbl_Table
But when I use a query parameter linked to the report parameter, the preview is blank. For the query parameter, I use the below query:
SELECT ID, Name FROM tbl_Table WHERE ID = #parameter_a
I am clueless on this. I have also tried keeping a default value or removing it. Refresh/View Report doesn't work either.
PS: I am using MySql ODBC connection. Both options in report work fine when used in a c# application and rendered programatically. Tried re-installing current version, older version as well.
Reading the MySQLCommand documentation, there is reference to an older parameter syntax (not sure what version of MySQL you are using in this scenario).
Using the '#' symbol for paramters is now the preferred approach
although the old pattern of using '?' is still supported. Please be
aware though that using '#' can cause conflicts when user variables
are also used. To help with this situation please see the
documentation on the 'allow user variables' connection string option.
The 'old syntax' connection string option has now been deprecated.
Instead of using #, can you try with ?:
SELECT ID, Name FROM tbl_Table WHERE ID = ?
The order of the parameters used in the query will have to match the order of the SSRS report parameters.

Is there a solution for localizing "parameters/prompt" in SSRS 2008 R2 or 2012?

I'm using now SQL Server 2008 R2.
My website shows the report exactly as it is, including the container where the parameters appear (the client prefers it that way).
However, my website solution includes localization (Portuguese, English, Spanish).
I've tried to translate the parameters by creating one parameter for each language, and then show them according the selected one. It didn't work in SSRS 2008. Because I don't know how to find the visibility properties of prompt.
Does anyone know a solution... Or if SQL Server 2012 has solutions for translating parameter's prompt, or conditional visibility?
Thanks.
The only solution I've found so far (SSRS 2008, 2008R2, 2010, 2012) is to break the DRY commandments, and duplicate the reports with language codes as part of the report name (e.g. MyReport_sp.rdl, MyReport_de.rdl, etc) and then place a web service between the client request and the SSRS instance. The web service then has to field the request to the correct report based on a "Culture" parameter passed with the client's request.
This is NOT a good solution, though at least the Culture param is used in localizing the rest of the report as well. We still have hopes that at some future date MS will add prompt localizability and we can rename the report to MyReport.rdl and just have everything actually localized. Hmm, what a concept...
Another workaround would be to just put a number in the prompt for the parameter then prefix the label of each parameter with the localised version by either using "get values from query" or by using the expression builder with a switch statement in the label expression.
For the get values from query option you would have a dataset something like this if you have the translated versions in the query:
SELECT ParamLabel, ParamValue
FROM MyLocalisedParameters
WHERE UserLanguage = #Language
Or like this if not:
SELECT
CASE #Language
WHEN 'pt-PT' THEN 'Selecione Departamento: ' + ParamLabel
WHEN 'es-ES' THEN 'Seleccionar Departamento: ' + ParamLabel
ELSE 'Select Department: ' + ParamLabel
END AS ParamLabel
, ParamValue
FROM MyParametersTable
in both cases creating and assigning the Globals!Language to a Parameter called #Language.
Or if using the expression builder for a hardcoded set of values it would look something like this:
either way the end result would look something like this:
Not perfect but functioning and easier to maintain than several copies of the same report.
If you want it to look a bit tidier then just have the Parameter prompt as only one entry in the parameters list and set it to the default value to avoid repetition on every line.
There is none...
As per connect.microsoft.com, this feature has been requested after SSRS 2005 has been released, and while it is on Microsoft's TODO list, the programmer time to do this has never been allocated, and hence in 2012, SSRS is still not capable of doing that.
Although it's (with much effort) possible to translate everything else, it's not possible to translate the parameter prompt.
There is NO conditional visibility either, visibility of parameters is fixed.
Also, there is no way having SSRS use a supplied language instead of the one set in the browser language settings.
The only thing that you CAN do is write a C# program that loads your XML file, get's the report's parameter name(s) (and possibly the report's name as well), looks them up in a database, and automagically creates N reports for n languages.
Then, you have to redirect your users to the report in their language.
You then only need to write an upload tool, because you won't want to do that by hand.
The other way is to use the ReportViewer control, and re-implement parameter selection.
I think there's CrissCross that tries to do that, but it failed in all but 2 of the reports that I tested.
An evil hack would be:
parametername: babla_language1 / blabla_language2 / blabla_language3 / blabla_language4
and then use jQuery to get that string. do string.split('/')[index_of_language]
and then prey that / is never within "blabla_languageXY"
Edit:
I actually did that. You have to use setInterval to do it, because there is no way to detect change when you select a parameter.

Lookup function works, until deployment

I'm working with Visual Studio Reporting Services 2008, and I've come across an irritating problem. I have a cell in a table that uses a Lookup from one dataset to find the information to display in another. The code is as follows:
=Lookup(Fields!place_id.Value,
Fields!id.Value,
Fields!name.Value,
"Centres")
The place_id and id are from one dataset (Dataset1) and the other is from the dataset "Centres". This works fine in the preview, but not after deployment. When I try to deploy, I get an error message (where textbox22 is the cell in question):
The Value expression for the text box ‘Textbox22’ refers to the field ‘name’. Report item expressions can only refer to fields within the current dataset scope or, if inside an aggregate, the specified dataset scope.
Surely, by having "Centres" there in the expression, that is the specified scope. Any ideas?
Based on your shared information, I can say that your SSRS development version is SSRS2008R2 and your report server version is SSRS2008. Since Lookup function is not supported in SSRS2008 and lower version. This is the reason that you are getting this error in deployment whereas preview in working fine.
For any additional information regarding Lookup Function, you can take a look into Lookup Function

What are the best strategies to debugging SSRS?

I am looking for ways to track down where an SSRS error is occuring.
I have a report that is about 90 columns wide with multiple formulas. The problem that I am having is that on one of the formulas there is a divide by Zero error. I have implemented the answer from Robert Harvey in this question but I still get the error. I know that the answer works as I have tested it on a small report.
So the question is: How on earth do you identify where an error is occuring in SSRS when SSRS only reports that an error occured?
EDIT The error as displayed is
An error occured during local report processingAn error has occoured during report processingCannot read next data row for the dataset MainReportDivide By Zero error encounted
EDIT
Rather than use the IIF statements and others, I'd reccomend doing the following... Add a custom function to your report, go to report properties and the code tab. Create the following. To specifically identify the field that is throwing the error, you can change this to return a string and maybe "#OOOOOOPS" so it sticks out on the report.
Public Function SafeDivision(ByVal top As Decimal, ByVal bottom As Decimal) As Decimal
If bottom = 0 Then
Return 0
Else : Return top / bottom
End If
End Function
After adding this function, go to the expression view for all of the fields that you have where division will occur. You can execute this newly created function by typing in:
=Code.SafeDivivision(CDbl(1.24), CDbl(0))
ORIGINAL
If you run the report within visual studio, does it tell you which specific textbox/label/field the computation failed in? That should help pinpoint where the issue is coming from, but you could also make sure that you never perform the division with 0 in the denominator by looking at the code below...
//myBottom would be the value of the denominator
//myTop would be the value of the numerator
= IIF(myBottom <> 0, myTop / myBottom, "")
Follow Up
The problem ended up being the SQL Query. As part of the SQL query, I had as In clause like the following.
Select ID, Name, price/kg as unitpice from products where ID In (#ProductIds)
SSRS uses exec sp_executesql and string.replace to inject the ID's into the IN clause.
The problem I had was I would run the query in SQL Studio Manager. with all the variables entered and it would work as expected. but under SSRS it would fail with the divide by Zero error, and there was no real clear indication where the error occured.
After I made a copy of the report and deleted items one by one until there was litrally nothing left on the report to render and it still produced the error, I turned my attention to the SQL Query.
It was there that error was occuring. I only found it after using SQL Profiler to find out what SSRS was actually running.
After that it was relativly easy fix of deleting the offending line and returning the seperate parts of the divide and run it through the function that RSolberg suggested.