I've defined a report in Cognos Report Studio.
I've also exposed this report in IBM BAM Business Spaces. I've used Report Viewer widget for that.
This widget allows end users to remove filters defined for the report. The data security is preserved (FGS applied), but they can access irrelevant data for specific report.
I would like to disable this (removing filters). Unfortunately this build-in widget is not allowing that.
As workaround I'm trying to use some other technique than filters to limit the data. I was trying to apply the filtering within the slicer.
My data is quite flat, and the data item I want to filter is not defined as dimension. That's probably the reason why it's not working for me.
I have a table with multiple columns.
My slicer definition:
filter([A_Events Query Subject].[ATracking_Events].[Status Code],
[A_Events Query Subject].[A_Events].[Status Code] = 'Q')
Anyway, all data (not filtered) are shown as a result.
Any idea how this can be solved?
Related
TLDR; is there a way to understand at runtime which format is ADF using for dates behind the scenes? In particular the format used to render dates in dynamically generated sql code?
In the Oracle ADF Application I'm working on there are several table filters (by that I mean the field over the column in which I can write text/number/dates to query the table).
Filtering this way, the framework modifies the query of the View Object, adding the appropriate where clause. On the page there's also a button "Select all" that allows me to select all the data that's rendered in the table (there is a selection checkbox).
In the specific case, the query from the VO is used to aim two different goals:
update the rendered data in the table
if I press the "select all" button a function in the backend database is called (callable statement calling the function), passing as a parameter the query.
The first task is successfully reached (as the table is visually updated), but we had an issue with the second one.
The backend function uses the query to select all the extracted data (as iterating in ADF with java would be too slow).
The problem is that the where clause isn't correctly generated for the backend database (which is also oracle).
Basically the generated WHERE clause (which was added to VO's query automatically by the framework) was
WHERE record_date = '2020-10-12'
which I had to change to
WHERE record_date = to_date('2020-10-12', 'YYYY-MM-DD')
in order to have it correctly executed by the Oracle Db.
So now it's working (yay), but my concern is: isn't it dangerous to assume the date format will be 'YYYY-MM-DD' on every application's instance?
I think this 'YYYY-MM-DD' is the format in which ADF is managing dates (as the value is written as '2020-10-12' in the query).
But is there a way to understand at runtime which format is ADF using for dates behind the scenes? Or does it always use 'YYYY-MM-DD', or am I completely off-road and the storage format is another and I should ask which format does it use to render dates? But dates on page are visually rendered in another way :/
Sorry for my lack of expertise and have a nice day!
Update
The value of the query field, which I'm getting by calling
this.getNamedWhereClauseParams().getAttribute('vc_temp_1');
is of class
oracle.jbo.domain.Date
and by printing it I obtain the date in format YYYY-MM-DD.
Would it be possible that the framework was simply using Date.toString?
This would raise another question: how can I be sure of the pattern used by Date.toString? The documentation isn't clear about it (and it says that it should be used only in development, so this is quite a remote scenario).
What you named 'Filter' is called 'Query by Example' or QBE in short. See the doc for more info.
You can change the query passed to the server using a bean method. Look at e.g. JDev 12.2.1.3: Multi select component table filter for a sample.
Using dates in ADF is always dependent on the current user's settings. If the user don'T use a specific locale the default is 'yyyy-mm-dd'. This can be changed at different points, starting by the entity objects, view objects a,d finally in the UI by using converters.
The best way to use dates depends on the use case.
I have a filter by different divisions (Management, IT, Finance, etc). I currently have it so that I can do data quality check for each division. However, I don't want this filter to show up users of different divisions. Right now, the IT folks can see the division filter and as they are restricted to see only their division's data, they only see the "IT" as the only option in the filter. I would like for them to not see the Division filter at all as it is not useful for them, but I do need it for data quality purposes.
One of the solutions is to publish a workbook without the filter for the end users and another workbook with the filter just for you in a different folder (which only you can access). This one works always but you have 2 versions of the same report.
Or you can try it with parameters as described here:
https://www.theinformationlab.co.uk/2017/01/26/hiding-parameters-filters-tableau/
I have a Tableau dashboard with various visualizations created from 3 data sources (i.e. A,B, C).
Each data source has a relationship (join) with the same secondary data source (i.e. D), and the secondary data sources provides information to create a filter for each data source. In other words, there is the following relationship for my data sources:
A - D
B - D
C - D
I would like to create a global filter on a dashboard I have created. I would like one filter card from "D" to show up and be applied to "A," "B," and "C" at once rather than having a separate filter card show up for each data source.
I tried to create a global filter via a parameter and calculated field, but the parameter requires layers of connections because data sources "A,B, and C" only have "D" in common.
Thoughts?
Its not completely clear from your question, but it sounds like you are using Tableau data blending on your worksheets to include data from multiple data sources, rather than a join to create a data source based on multiple tables. If all your tables are on the same database server or spreadsheet, then traditional joins are usually more efficient than data blending.
The following approach often works well.
Instead of using Tableau's quick filter feature, create a worksheet based solely on D that shows the values you wish to use for filtering. It can be a simple list of names, or a bubble chart or anything you like. Use that worksheet as your filter by creating actions where it is the source and all the other worksheets on your dashboard are the target. Typically, you would want to specify the field names explicitly.
Data blending is useful but can be complex. Depending on details, you may need to make D the primary data source on your other worksheets. Experiment.
The parameter and calculated field you mentioned can be even simpler and faster than using actions, but users are restricted to selecting a single value for a parameter unlike the filter action approach. (Of course, one parameter value can represent multiple values in your target data source field depending entirely on how your calculated field interprets the parameter).
I can't tell why that didn't work for you or what you mean by "layers of connections". You might consider clarifying that part of your question.
I am using SSRS through VS 2010 and have the following questions:
Can I define a drop down menu without defining a dataset?
I have a dataset defined, is there anyway to add "manual" values to this dataset? The background requirement of this is that the report query is based on this dataset. However I want to have an option in the dataset where it says "all" in order to allow the user to see everything instead of narrowing down results based on the dataset.
Thanks,
Bruce
I am a newbie to SQL Server reports and found my answers:
For the first one, can simply create a table and use a dataset on the created table with customzied values.
Same goes for the second one, the manual data can be added to the table itself.
This is my first attempt to create a Visual Studio 2008 report using parameters. I have created the dataset and the report. If I run it with a hard-coded filter on a column the report runs fine. When I change the filter to '?' I keep getting this error:
No overload for method 'Fill' takes '1' argument
Obviously I am missing some way to connect the parameter on the dataset to a report parameter. I have defined a report parameter using the Report/Report Parameter screen. But how does that report parameter get tied to the dataset table parameter? Is there a special naming convention for the parameter?
I have Googled this a half dozen times and read the msdn documentation but the examples all seem to use a different approach (like creating a SQL query rather then a table based dataset) or entering the parameter name as "=Parameters!name.value" but I can't figure out where to do that. One msdn example suggestted I needed to create some C# code using a SetParameters() method to make the connection. Is that how it is done?
If anyone can recommend a good walk-through I'd appreciate it.
Edit:
After more reading it appears I don't need report parameters at all. I am simply trying to add a parameter to the database query. So I would create a text box on the form, get the user's input, then apply that parameter programmatically to the fill() argument list. The report parameter on the other hand is an ad-hoc value generally entered by a user that you want to appear on the report. But there is no relationship between report parameters and query/dataset parameters. Is that correct?
My last assumption appears to be correct. After 30 years in the industry my bias is to assume a report parameter actually filters the SQL data using the given parameter. This is not the case with .rdlc files used by Report Viewer. These report parameters have nothing to do with fetching data. Sounds like this was a design decision on Microsoft's part to completely separate the display of data from the fetching of data, hence, Report Viewer has no knowledge of how data may be fetched. Best way for me to conceptualize this dichotomy is to think of Report Parameters more as Report Labels, quite distinct from the dataset query parameters.