We create several crystal reports based on SQL Server - usually 2005 or 2008. Broadly there are 2 kind of reports
a) tabular reports - which shows some data in a table (for example, invoice list)
b) document layouts - which shows data in specific format - usually from one or two main tables - and several secondary tables (for example, invoice)
We sometimes use tables directly in crystal. Or create a procedure in SQL and than use that procedure. One invoice could refer to usually around 10-12 tables. Most of these linked using left outer join to the primary invoice table.
What option is better - using tables in crystal (and let crystal create and run the sql query) - or create a query - and than use that query in crystal. Which one will give better performance?
There will be no difference in performance between a query generated by the 'Database Expert' versus the same SQL added to a Command. One caveat: ensure that the record-selection formula can be parsed and sent to the database (a filter applied WhileReadingRecords will definitely be less efficient that a pure-SQL one).
Reasons to prefer the 'Database Expert':
prior to v 2008, Command objects didn't support a multivalued parameter
easier to manage (somewhat subjective)
Reasons to prefer a Command:
you can add hints
you have more finely-grained control over the SQL (e.g. in-line views, CTEs, more-complex JOINs, subselects)
Personally, I try to avoid stored procedures as they offer minimal performance benefits, but require a more-signification investment in development and maintenance.
In the end, there is no substitute for performance. Try you query both ways and measure the results.
Coding it yourself will almost invariably run faster -- after all, you know what your data looks like, and Crystal doesn't. Also, there are things you can do in manual queries (windowing functions, for example) that Crystal can't.
Crystal had tendency to do some crazy stuff behind the scenes. You can view the "Show SQL Query" under the Database menu options to see what it creates. If find it easier to write the query in SQL as I can optimize it myself much easier. I also prefer to do any calculated/formula fields in SQL to and just use Crystal as a display interface. If you do put logic in crystal remember that it is running that logic for every record returned... so if there are conditions that exclude a record from a formula put that first to limit the time spent in the calculation.
Related
We're using Tableau 10.5.6. I used a reporting tool years ago called Oracle Sales Analyzer. In that tool you could get to the queries generated by the reports and graphs you created through back-end catalogs using their command line.
There you could rewrite the query to be more efficient by fine-tuning the code if you needed. It was a very cool feature of that reporting tool for geeks like me who like to dive into the back end of the product and tune it at a very low level.
My question is, does Tableau have any of this type of facility? Is there a way to get to the queries that get stored once you create a report or a graph. Also is there command line where you can access these catalogs if they exist? Otherwise are these queries just stored in ASCII flat files that can be accessed by a user.
Thanks!
There are two ways that Tableau will query a database.
Option 1: Custom SQL
In your data source, you paste in the sql you have written and Tableau will pass that query through to the database. This gives you complete control over the sql, including adding any indexing hints you may want. See https://onlinehelp.tableau.com/current/pro/desktop/en-us/customsql.html
Option 2: Use the Tableau data source designer
This is what many people do. Here, you visually design your data source with the joins. Tableau translates that design into what the Hyper engine considers to be the most effective way to run the query. Sometimes, Hyper translates that into a regular sql statement. Sometimes it does some additional things to help boost performance, like breaking it up into different queries. A lot depends on the db engine you are connecting to. There is no "sql" stored in a flat file for this. Tableau just translates your design at run-time. The Hyper engine does a good job with fine-tuning, assuming you have an efficient database design with proper indexing and current table statistics.
There is a way to see the sql from option 2 at run-time using Performance Recording. Performance Recording keeps track of each step of the visualization process and will spit out the sql statement(s) that Tableau ran to generate your dataset. The sql is not stored in the twb file though, it's a run-time analysis.
I have a fairly simple question concerning a design with a view for how reports would look like when the program is complete. I use Java, with JasperReports for my reporting needs.
Correct me if I'm wrong, but JasperReports does not make elements from different tables overlap to make sense, for example, in my case, I would like the the sales and receipt of an Item in a single report ordered by date (Sales and Receipts overlap). I have a sales table and a receipt table in the database.
The question is, should I redesign my database so that both sales and receipts are stored in the same table, or is there a way jasper reports can merge both tables and make reports overlap in a tabular form?
You can write an SQL query, from which the table in jasper-reports will take it's data.
In this SQL, you can write a join that will get you the data from both of the tables.
So you can leave the design of your tables as it is now.
We have Sql server database and it is designed on snow flakes (Facts and Dimensions) schema. These tables don't have PK and FK relationship. Instead we are maintaining these information in metadata tables.
Is it possible to design reports in SSRS on these tables?
I want to design reports by combining different columns from tables.
Any help would be appreciated.
Assuming that the Fact and Dimension tables are held in a conventional relational database, you can access them in SSRS using conventional SQL queries.
If the database structure is OLAP, you'll need MDX to query instead of T-SQL
yes, of courser you can!
It doesn't matter how your data is structured on your database, if you manage to build a query to display it, SSRS will be able to read it on a DataSet and use it on the report
A SELECT statement is sufficient. A view or a stored proc are preferred. It's hard to imagine a SQL database that doesn't support those options.
We have several reports that do the same formatting operations (e.g. displaying "PASS" or "FAIL" if a value is within a particular range.)
Without Crystal Reports Server, is there a way to share functions between reports so that they do not need to be duplicated? I understand I could do this with a user function library but I would prefer not to port all of the crystal functions to UFL.
Using Crystal Reports 2008.
The only other option I know would be to port the functions to Stored Procedures or Database Functions. This is actually a better implementation (in general) as the Crystal Reports Client Processing is much slower than the SQL Server. so your pass or fail would become a function or stored proc or even the use of a case statment in the Select Query.
Good rule of thumb with crystal reports, flatten out the dataset as much as possible before returning the dataset to Crystal. This will allow you to use the power of the Database server before relying on the Client to handle the processing. The perfect example is to return 1 million rows to the client but flatten it out to only displaying totals from 5 groups. Crystal will choke on the fetching of 1 million rows before it can process the totals.
I recall that earlier version of CR support the notion of a shared repository in addition to the repository that is available via BusinessObjects (nee Crystal Decisions) Enterprise.
I haven't found any mention of similar functionality (meaning a shared, non-BOE repository) in version XI+.
I'm really at a loss as to how to procede.
I have a very large database, and the table I'm accessing has approx. 600,000 records. This database is accessed using an accounting application, which provides the report with the SQL query by which this report accesses the database.
My report has a linked subreport which has restrictions that are placed in the report header. When this report is run, the average time to refresh, using a very base query is 36 minutes. When adding two more items to the query, the report takes 2.5 hours.
Here is what I've tried:
cleaned up the report only leaving items in absolutely necessary - no difference
removed most formulas (removing the remaining formulas makes no time difference)
tried editing the SQL query - wasn't allowed because of the accounting application
tried flipping subreport and main report - didn't work
added other groupings - no difference
removed groupings - no difference
checked all the servers for lack of temp disc space - no issue
tried "on demand" subreport - no change
checked Parameters (discrete vs. range) and it is as it should be
tried bursting indexes, grouping on server, etc. - no difference
the report requires 2 passes. I've tried getting it down to one pass unsuccessfully.
There must be something I'm missing.
There does not appear to be any other modifications to the report using regular crystal functions. Is there any way to speed up the accessing of the data without having to go through all 600,000 records? The SQL query that accesses this data is long and has many requests. It is not something I can change.
Can I add something (formula?) that nullifies these requests? I'm reaching now...
Couple of things we have had success with is adding indexes to the databases, and instead of importing tables into the report, we instead wrote a stored procedure to retrieve the desired results.
If indices and stored procedures dont get you where you need to be you have reached the denormalise until it works part of life with a database. You might want to look at creating an MI database with tables optimized for your reporting needs; and some data transformation scripts that can extract the data from production to your MI database. Depending on what it is oracle / ms have tools to help you do this.
We use Crystal Reports with a billing system, and we had queries in the database that take over 1.5 hours to complete. This doesn't even take into account the rendering/formatting of the reports.
We created Materialized Views and force the client to refresh them daily. A materialized view is basically a database view that holds the returned dataset. The dataset is not refreshed unless you explicitly tell it to refresh.
Do you know what the SQL query is? If so, you can move the report outside the accounting application and paste the query directly into the Command in the database expert. I've had to do this in a couple of cases with another application I work with.