I'm used to generate reports based on my database tables record and don't have any problem presenting it.
But now, some presentation requirements coming up that seemed to be much complicated to handle if I don't create a dummy table as a repository.
Current System Details and information:
System Type: Inventory Accounting
System design and setup: Can generate reports base on date selected
(transaction date) : Individual Reports for : Balance Sheet (BS),
Income statement(IS) and Cash flow statement (CFS)
New Report requirements:
BS, IS and CFS reports should have different format and display (Mostly the update wanted are the change in Layout display)
Saving of every generated reports
I'm thinking to create a dummy db table because of the 2nd requirement in w/c to save every report generated.
Before, I do create repository table for complicated reports but replaced/erased when another user generates the same report.
Question:
Base on the new report requirements is it really necessary to create dummy table for this type of report requirements?
Well, in real functionality *they can be generated at any time* but for report and recording purposes and as to performance perspective does saving generated reports really make sense?
For those DB Accounting guru, does saving BS, IS and CFS generated reports is a good practice?
Based on the new report requirements, is it really necessary to create a dummy table for this type of report requirements?
Yes, although I would call it a report history table.
Well, in real functionality they can be generated at any time but for report and recording purposes and as to performance perspective does saving generated reports really make sense?
Saving generated reports makes sense from an audit and accountability standpoint. You'd have to ask the people that gave you the requirements, but I've worked on systems where we had to record who made what system queries from what terminal / workstation when. System changes to the database were more strictly monitored. The auditing was required by law.
Related
I have 187 reports in a live SSRS/SSAS scenerio. I have a requirement to update the cube all of the reports are feeding from. The requirement is spawned from a change request to one of the reports.
Is there a quick way to determine whether or not I have broken all the other reports based on the new cube design (in short terms, how do I perform automated regression testing?)
Thanks much!
Best thing I can think of is to set up a subscription for every report that goes to an empty folder on a file share, or email if you prefer. If there is less than 187 reports in the folder, then you have a broken report.
You can then create a query of the SSRS database subscriptions table to find the subscription that errored, and which report it was, to go test it further.
If you want to automate the creation of the subscriptions for the reports as well, you could use something like this tool. https://www.2ndrock.com/software/subscriptionmanager/subsmgr.html
I am working with TFS 2013 and generating reports with SSRS however I have benn tasked with creating a detailed report showing all steps and acceptance criteria for each test case and list the available parameters. I have searched and searched the web and have not found any examples that show the test steps.
Thank you in advance.
In most instances the Test Steps fields are not set to reportable by default so they are not populated in normal reporting databases. You'll need to set them to reportable or create a new data source targeting your TFS transaction databases instead of the Warehouse/Cube databases.
It is not recommended you target transaction databases with reports since this can affect performance of TFS when reports are run. Especially a field like Test Steps since it might need to pull a lot of data at once.
Use the witadmin command to change the reportability of the Test Steps field. Using detail will only put the information in your Warehouse while the detail option will put it into the Warehouse and the Cube. Where you want it depends on how you write your reports. Once set the reportability type can only be changed in limited ways, so please keep this in mind when deciding how you want it set.
witadmin changefield n:<nameOfFieldToChange> /collection:http://yourcollectionURL:8080/tfs/YourCollectionName /reportingtype:<dimension,detail>
See the reportable attributes section for details.
I have a universe and multiple reports built on top of that universe.
Is it possible to configure that when a certain data subset in universe comes, the certain reports are sent to the end-user (stored on file system in PDF format)?
Basically, the question is - is it possible to create a trigger based on the data that are comming in the universe. This trigger triggers report distribution (not all reports, but only specific ones).
As per my understanding you need to have this reports in some file system in pdf format. am i right? I f so you can schedule the particular report that needs to be distributed.
Regards
Niki
There is a constant change (!) in our database, new columns are often added.
Is reporting services the tool to choose for reporting in this case?
Case1: Developers add a new column to a table used in a report. Will the old reports created with a report model based on the old table still work?
Case2: Developers add a new column, and end users want to be able to report on it. If we update the report model, will the old reports based on the old report model still work? Or do we have to create a new report model every time the end user wants to report on a newly created column?
Regards
Lars
Reporting services has required strategies for change management. So, adding new column to a table in the underlying data source does not affect the reports.
If you want to include a newly added table column into your report model you should update (not create from scratch) your report model. Updating the report model automatically insert your new column to the model and does not break your old reports. on the other hand, updating report model does not update/delete the existing item if you change them (like table/column name or column data type etc) in the underlying source. You should manually change them at the report model and at the affected reports.
So, in your case, you won't be having any problem with reporting services.
Here i'm adding a change management section of the Reporting Services/Report Model document and strongly suggest you to read it.
Change Management
Models and the reports based on them
have many internal and external
dependencies. Therefore, you need to
consider the impact of changes
introduced into the dependency chain.
Report models based on relational data
sources use GUID attributes to
identify each entity, attribute, and
role. As mentioned, the report
model-generation process sets the
GUIDs, which are re-created at each
generation. For that reason and to
preserve edits on the report model,
generating a new report model each
time a change occurs is not an option.
You must work with the existing model
and update it, either manually or by
using the update options described
below.
The Semantic Query Engine
manages missing attributes when they
are not critical to report processing.
This functionality is in place to keep
reports running when security
attributes preclude users from seeing
some attributes in the report that may
be allowed to other users. Thus, if a
user is not allowed to access a field
such as the employee home telephone
number, the Employee Listing report
will run for that user but will not
show the excluded information. This
functionality works to your advantage
when models are edited to delete a
non-critical attribute. The report
will still run after you have removed
an attribute, although the report
might show a blank field. However,
query or report processing can be
broken by other changes to the model.
Remember that you should not overwrite
a model generated from a relational
data source when any reports depend on
it.
Schema Changes
If the underlying schema changes and
report model entities or attributes
are affected, you might have to update
the report model accordingly. To do so
in BIDS, use the Autogenerate command
on the Reporting Model menu. You can
also select Autogenerate from the
model item's context menu. By using
the context menu, you can select which
item on the model you want to update
without having to update the entire
model.
The autogeneration process will
show informational, warning, and alert
messages. These messages will show all
items in the model that are
out-of-sync with the underlying DSV,
even though those items are not
specifically included in the item
selected for autogeneration. This
functionality helps detect potential
errors than may lead to unpredictable
errors when running reports based on
the model.
Automatic update affects
newly added items only. The
autogeneration process will add any
new entity, attribute, or role found
in the DSV, but will not delete or
change any entity, attribute, or role.
Therefore, you need to manually manage
updated or deleted items. The messages
shown at the end of the generation
process will highlight any entity,
attribute, or role that needs to be
updated in the resulting out-of-sync
model. You will have to update the
model manually or revert the DSV
changes to maintain model-to-schema
coherence.
Data Source Changes
You can develop and test your model in
a development environment and then
deploy the model in a production
environment easily by changing the
connection string in the data source
file that the DSV uses. The two data
source schemas must be identical.
Note that the DSV contains statistics
based on the actual database data. As
mentioned in the section "Statistics
in Report Model Generation," the value
of those statistics will drive some
algorithm decisions during the model
generation. Therefore, if the
development database data is
significantly different from the
production database data, the model
might not be optimized for the data
that will eventually be used.
Hope this help.
I would like to use SQL Reporting Services 2008 to generate my reports, but I want to use my own UI for specifying the report type, columns, parameters and everything. I want to be able to take these criteria, and then kick off an asynchronous request to SSRS and have the report emailed to me. Is this possible? I don't want to go all the way down the road of researching SQL Reporting Services 2008 only to find that it doesn't do what I need it to do. Also, I will have a ton of DB partitions that the data will need to be pulled from. Some reports will need to pull data from only one of these, but other ones may actually need to span different databases. Is it possible when sending a report request to SSRS to specify what servername/database to pull the data from? Is it possible to tell it to take the data from multiple databases and combine it? Thanks.
Like Crystal Reports, ActiveReports and other report generators, SSRS has two basic elements behind each report: the SQL query and the report layout. No matter what tool you use for the SQL -- it can be inline SQL in the report or a call to a stored procedure -- it's going to be the same query. Multiple databases are fine as long as you can specify them up front.
You can have parameterized queries, so the user is prompted to input the relevant filters (customer ID, product group, date range, whatever).
Doing the report layout is similar to other tools -- you drag and drop controls like labels onto the report, and set their formatting.
SSRS does provide a lot of options for distributing the report, including email. You can embed the report in an ASP.Net web page, leave it on the report server site for users to browse to, run it in the wee hours of the morning and cache it so every user doesn't have to wait for the lengthy query to run.
It's a great tool. I think it will be worth your effort to experiment with it. I would wait on creating the customized UI until you've exhausted the possibilities inherent in the tool.
SSRS is not designed with this scenario in mind, for that matter I am not sure that any out of the box reporting solution is going to have an elegant solution for this. While SSRS can do what you are asking (as well as others), it is by no means quick or easy. You seem to be looking for an advanced ad-hoc solution with dynamic sourcing of the data. I would first question the requirements and determine if the business scenario really justifies such an implementation. I would weigh custom building a solution vs your learning curve with a BI reporting solution. You may find that it is easier to just build something on your own.
I think the heterogeneous dynamic database mashup is probably going to be the most challenging part.
Depending on what your scalability requirements are, one place that has that part covered, and a report writer, is Access. (Duck! Incoming!)
I think you may be creating a rod for your own back to a certain extent as RS ships with a few interfaces for report creation.
Mind you the end product is an rdl file which is nothing but xml, so you can write them by hand if you really like.
Multiple data sources are supported, but combining them on a single control/chart/etc are not, so you'll need to configure yourself a cross database capability from one of your data-sources prior to the report request if you want to do that.