Can I change the database server and database a report is pointing to dynamically? - crystal-reports

I have a Crystal 2008 report that will be deployed to an InfoView server. There are four different databases the user might want to execute the report against. Each of the four databases have exactly the same schema. Only the data in each is different. Each database corresponds to a plant we have around the world.
Instead of creating four different reports (each one connected to one of the four databases), am I able to dynamically change the server/database the report hits based on a value the user enters into a parameter? I'm really trying to avoid having to create four identical reports except for the database connection on each. If this isn't possible, how do developers typically deal with this sort of scenario? I would imagine it's fairly common.
Thanks very much.

InfoView doesn't support dynamically changing a report's datasource. You certainly could modify InfoView source to suit your needs with the BusinessObjects Enterprise SDK, but that will be a challenge and won't be supported by BO.
Another option is to build a custom portal with the BusinessObjects Enterprise SDK, but this will require quite a bit of coding as well.
Probably the best option is to publish the report multiple times, set each datasource as appropriate (via the CMC), and change the name of the report to give an indication of its datasource (via the CMC). I there is a report property in the CMC that will save the datasource settings so you can quickly republish the reports if you make a change to the original.

I'm not familiar with InfoView, but it is quite common to do what you describe, I've done similar things with Asp.Net and Winforms; if you have access to the Crystal Reports object model, there are extensive options for setting logon info, I think it is SetDatabaseLogon; if you have subreports, you have to set the login for each of those separately.
The schemas do have to be completely identical, or the user will get warnings.

Related

how to build domains in tableau?

Domains are virtual view of a data source that presents the data in business terms, allows for localization, and provides data-level security. ADomain is a metadata layer that provides a business view of the data accessed through a data source
this is domain definition as in Jaspersoft reporting tool.
I am currently given the task to build or come with a design to create some domains in tableau.. (like in jaspersoft)
examples of domains in jaspersoft
In jaspersoft when you click on a domain : ex customer domain: you will see the list of tables (that are selected)
How to do the same in tableau?
Please guide me on this..
The meta data layers in Tableau are quite lightweight compared to other BI tools, which is ofter a plus, but seems to fight against your assigned task.
Usually the best approach in Tableau is to learn to use the tool well, build visualizations for your business domain, test and refine them, and then later focus on factoring out common meta-data as your Tableau projects grow. That tends to work better than insisting on a big meta data design up front approach.
Still as you learn to use Tableau, the features that you'll want to understand related to your question are everything about data connections (which define how to connect to a data source, and the fields, data types, calculations, groups, sets, field roles etc). You can start with a data connection in a single workbook and then save the connection separately (typically on the server) so that it can be shared among multiple workbooks (to reduce duplication). You can also use Tableau Server like a proxy for your database.
For security, you can look into the groups and access controls provided by Tableau Server, along with user filters.
Some of the features you ask about might be more properly relegated to the database server, such as by defining common views visible to different users.

Approch for JasperReports

I am new to JasperReports, I need a few heads up before going forward with my development. My colleagues told me they are able to generate a basic report, but they are stuck with what approach should be used.
I was told we could:
write the queries in each report
run the queries outside the report, and pass it to the report as a
datasource
Which approach is preferable? Does passing the datasource have any performance hits compared to passing the bean? Also would like to know does first approach run in a different jvm?
Current Project Architecture
Struts 2 - Spring 2.5 - Spring JDBC
If you and your team are just starting out with JasperReports I would recommend embedding the SQL query into each report. It makes building the reports in iReport much easier, since you can constantly preview your report with live data while working on it.
As far as performance, I do not think it really is not going to matter in the most basic of examples. If it is just a SQL query then no matter what scenario you use it is going to be using JDBC with the connection you give it. So I would ignore performance for now.
With that said, if you already have the data (i.e you have displayed on a screen and you want to allow the users to then export it to PDF or whatever), you could simply pass it in as a datasource and not take the performance hit of running the query again.
Another scenario you may want to use your own datasource is if you wanted to manipulate the data before it was exported in the report. Maybe some crazy sort that you could not pull off in SQL or something.
As far as your last question, it should all run in the same JVM (at least from my understanding).

How can I hard code logon parameters in a Crystal Report?

I have a Crystal Report that runs from within an MS SQL Server based application. The application can run reports based off of this database just fine, but now I need to run a report that also has another datasource, an Access db. When I run the report from the CR designer it works. However, when I run it from within the application it fails with incorrect logon parameters. I think the application uses its own logon parameters to run reports. I'm not 100% sure of this though because it happens "under the hood" of the application. Is there any way I can force the report to use a certain logon for the Access db?
It is fairly standard practice when an application embeds crystal reports that every table will be looped through and the logon parameters set to those of the application's data source.
The way i have achieved what you are looking to do in the past is create a view (possibly in conjunction with a linked server) in your application's database then you point the report at this/these view(s).
Good luck!

Problems using views directly in Crystal Reports with multiple databases

Working with Crystal Reports over a multiple database environment. In the past reports have been written un-generically (go figure). Trying to clean this mess up while providing new deliverables. Clients do not understand and always pushing for the shortest possible way and do not see the need for cleaning/tuning up existing reports to make them generic for all systems.
Have come across a number of reports built using a specifically written view for each report. The drama comes when cloning a view based crystal report and then trying to run the report via crystal designer on a database different from the original database the report was built on.
The report holds onto the original view object. Runs but delivers no output. At first I thought there were grants issues with the underlying views.
The solution is to update the view reference in the "Set Datasource Location" panel.
Wondering peoples opinions on using views in crystal reports. And if they have hit this situation before.
Obviously views have their uses but I do not see the point of adding another layer between a report and the sql statement(s) by making a specific view for the report when the sql can be plugged straight into the report. Only database procedures make sense to me when you are wanting to do more complex calculations and output.
Notes
The report runs fine from the application menus for the differing
systems (without changing the crystal datasource) SAP B1.
Those reports using views indirectly are NOT affected by this issue.
Pseudo screenshot:
Set Datasource Location (panel)
Current Datasource:
Report
server
properties
initial catalog: other database
view
properties
catalog: original database
From our experience using views for multiple servers/databases (or even tables with N-N relations) is preferred way. If anything changes in database layout or servers configuration, what you prefer - alter one view or multiple related reports?
Of course it can be related to fact that our reports are designed to work on single database. Our application always replaces all included datasource locations (tables, views) to current database, this allows easy reporting on different databases (including MSAccess and MSSQL ones). Such approach excludes cross-database reports, unless using views. Our reporting uses OLEDB interface too, not linked to datasources-connections, opened in application.
There are sometimes problems in designer, when it is opened directly with report file; set datasource location usually corrects them (you may need to set location for specific views too). If opened through our application, which saves report copy with corrected database information, designer works flawless.
And there are sometimes problems with underlying views, which cannot be easily transferred to different database layout. Fortunately view definitions can be altered without changing output layout :)
About customers - they of course do not want to change their working reports. You can be sure that you introduce some errors when replacing their reports with more universal ones - who wants that? No one.

JasperReports and custom data sources

I'm looking at embedding JasperReports into an existing web app for reporting. The webapp sits on top of an existing database which is ancient and complex, and really not suitable for report writers to use to write reports against directly.
What I want to look at is writing some kind of wrapper around our existing data access layer (written to make our life easier talking to aforementioned ancient and complex db). Does anyone have any experience of writing custom data sources for JasperResports, or of doing anything like this?
Updated
I guess I probably wasn't clear in my question - which is probably because my requirements aren't clear either. I want to provide some way that the end-users can use something like iReport to author reports against the database, and then to use JasperReportServer for scheduling/viewing of the reports. However, the database is really, really nasty and was never designed for use in this way. We've got a access layer around it that the webapp uses to talk to it. I want to keep my end users away from the DB altogether, and the idea of a custom data source that used the access layer seemed a good option. However, I've found very little documentation on how to do that. Maybe it's just a whole lot easier than I think it is, and I'm just trying to make a dead simple thing too complicated.
Updated
Thanks for the answers. I don't think my problem has been solved, but I think the answers have helped to inform the requirements phase.
Jasper reports allows you to use a "JavaBean" data source. You can load your data into any Java Bean structure and build the reports against that. Works well.
See the "Custom Data Source" section here.
Every JasperReports template can have two different data sources. One is hooking it directly to a database using some jdbc driver or, in your case, providing a collection of java beans (POJO's), usually list.
JasperReports template is similar to a method definition. It has a name, i.e. compiled JR object and parameters (data source and a list of input parameters of some of the most popular Java types).
My suggestion is to use iReport tool. Open some example that comes with the JasperReports bundle, analyze it and tweak it. It's not so complicated.
UPDATE
Letting customers authoring JasperReports templates, compiling and adding to the classpath means that you'll need to open your system too much. Usually clients provide description of a desired report and developer(s) create the data source and design the template. JasperReports can have parameters. If these parameters are exposed through UI users can change the behavior of reports in the runtime.
If you really need to allow more flexibility then use the API provided by JasperReports for authoring templates. I could imagine some simple DLS for advanced users to communicate with your system creating on-fly reports.