I have an SSRS report that I'm using multiple datasets (each in the form of stored procedures) to extract information for. The application that this report will reside in is used to enter audit information along with files. What I'm hoping to accomplish is a report layout similar to this:.
Since I'm dealing with a lot of 1-to-many relationships and tables, I thought it would be best to use multiple datasets rather than write a stored procedure that joins these tables, but maybe I'm wrong?
Can anyone recommend how to accomplish this layout? I've tried using Subreports embedded into a data matrix that displays the Issue description, issue images, action description, and action file fields but the output isn't very nice (see below) and I've been told that data matrices are better suited for numeric data rather than text data.
You should have a look here
It seems like it has been published for you.
Related
I've been given the task of updating some rdlc reports which I've never used before. Some of the more complex reports can have multiple datasets where each SQL query is over 10kb of text if copied to a text editor. I'm finding it difficult to wrap my head around some of the more complex SQL.
I've found that I can add custom VB code to the report and I was thinking it would be nice if I could use a simpler query for the dataset and then do some processing with custom code that could populate an empty table in the report. I haven't been able to find any examples of anything like this so I'm wondering if it's possible? If so, can anyone please give me a basic example of reading data from a dataset and adding rows to a table using custom code?
Thanks!
I am tasked to create a template that will be Filled up by Business Users with Employee Information, then our program will load this into the Database using External Tables.
However, our Business Users constantly change the template by adding, removing or reordering fields.
I am convinced to use XLSX instead of CSV so that I can lock the Column Headers so they cannot remove, add and reorder the columns.
However, When i query the External Table, it shows Non-ASCII Characters when reading XLSX because its in Binary.
How can i do either of the following?
Effectively Read Excel Files from External Tables
Lock the Headers of CSV Files?
What you have here is a political problem, but you are looking for a technical fix. Not a good fit.
The problem comes in two halves:
Somebody decided it was a good idea to collect user input in a spreadsheet, which it is generally not.
Users are fiddling with the input format, which they should not.
Fixes are:
Strictly enforce the data structure. Reject any CSV which doesn't natch and make the users edit them. They will quickly tire of tweaking the spreadsheets when they realise they're just creating more work for themselves. But they will also get resentful, so consider ...
Building a data input screen. It's pretty simple to knock up a spreadsheet-like grid UI. You don't need anything complicated in Java: Oracle's Apex is intended for exactly this sort of thing. Find out more.
However, if you are stuck with Excel as a UI I suggest you have a look at Anton Scheffer's excellent PLSQL as_read_xlsx package on the Amis site. Check it out. You'll probably need to replace your external table with a view over a table (perhaps pipelined) function.
I'm not sure if this has been asked already but I'll take a shot and see what happens.
For my work we have been using Excel to generate all of our reports from instrument data. We recently implemented a Laboratory Information Management System that uses an SQL database and Crystal Reports to generate reports. I've had the fun (sarcasm) of recreating every report we run in Excel in Crystal Reports. There's one that I'm having the worst time to create. The report compares information for two samples. It compares information for one sample and then information from a replicate of that sample. I've tried every which way to bring in the data but it just repeats it for every record that's in the query. Here's a general idea of what I'm trying to accomplish:
I have two queries that bring in the same data. One query lists the original sample that I need and the second query lists the replicate that I need to use data from to calculate as well as every other sample. Essentially they're the exact same query. You can see below in the link.
Here is the query. http://tinypic.com/r/wiu591/8
For the report, I need to pull the data for two separate samples and compare it using crystal reports and perform calculations. Below is a picture of the report, the RER field is a calculated formula. I've brought in this query twice and before anyone asks "did you make links"....yes, I have and it just repeats the data because these are essentially two different records in two separate queries that are the same. I'm at a loss for ways to configure this.
Here is the gist on what the report needs to look like. I'm open if anyone can see a better way to redesign it. http://tinypic.com/r/123ayh1/8
NOTE: In the columns that say Sample and Replicate these ones are C10575 and C10575R and the data for each is below.
Any help would be awesome.
So the answer was to bring in two queries into the same view. I used the management studio to accomplish this. I brought in the two queries and didn't link them on the primary key which was the sample code. I linked on what these samples had in common. From there I did some fancy SQL'ing to sort out the samples I didn't need and presto. Got exactly what I need to throw into the crystal report and perform the calculations.
i have a report which looks like this. it will be in PDF format:
alt text http://img52.imageshack.us/img52/3324/fullscreencapture121420.png
the user will input all the different foods, thus every section like NONE, MODERATE, SEVERE will be a different size and thus i need to be able to expand the sections during run time. in order to do that i should probably slice up the image and add different sections during run time. i dont know the proper way to do it.
please help me with a suggestion on how to go about fitting the text in the appropriate sections (but also keep in mind i have no control over how many foods are in each section, the user will decide this during run time)
I would create an iTextSharp table for each of your results (None, Moderate, Severe) and write out the table sequentially, in the order you want them to appear on your PDF. Each row in your tables would have four columns.
I found these articles useful for creating tables in iTextSharp:
iTextSharp - Introducing Tables
SourceForge Table Tutorial
Edit
Sorry, I didn't see the vb.net tag on your question. The pages I linked are in C# - I hope you can translate. I found that most of the iTextSharp samples you'll find are in C#.
It might be worth using a reporting tool rather than iTextSharp for formatted/tabular data?
We use Active Reports from http://www.datadynamics.com/ but I am sure there are others.
EDIT:
It looks like iTextSharp supports html-to-pdf conversion? Maybe thats easier to render?
Just did a search and found this: http://somewebguy.wordpress.com/2009/05/08/itextsharp-simplify-your-html-to-pdf-creation/
I am trying to figure out what is the 'best' (read: "your preferred method") way to generate datasets for SQL Server Reporting Services Reports (either 2005/2008):
In-report queries
Stored procedures
Views
But more than just choosing one of the above, why would you use that particular method? Also, please include your perspective (Developer/DBA/etc).
Thanks.
Stored procedures. I tend to write stored procedures for both parameters and the report data. By using stored procedures for parameter datasets they can be easily shared between reports. For report data I like to make certain that I draw a clear line between the data within a report and the formatting that comes out. By keeping that line it has been easier in my experience to test and promote reports to production.
Also, I find stored procedures a little easier to manage and troubleshoot than a view or in-report queries.
You should not bother with in-report queries, they are pretty much there to play with and practice. But you can hardly get a very good report writing a query directly in RS. Why..well for one thing a lot of sprocs can be reused not only for the application side but also the reporting side. Your application may have various stored procedures used to fill drop down lists / combo boxes that cascade (one relates on another). You may need this functionality for your reports as well. With stored procedures you could issue a call to the sproc from your report or your application. When the sproc changes (if it ever has to), you're ok because the updates you made to the application stored procedure also update your report's stored procedures.
My vote is definately for stored procedures.
I have been working with MS Reporting Services for about one full year now. I found that the best way to generate reports with this system is to run queries from your data access layer, via stored procedures.
If find that if you do it this way, you have all your returned datasets in one spot. It makes it easier to manage. All your database output is controlled from the same location.
Off topic but I would also recommend that you generate your RDLC files in memory. We have about 100 different report types. Instead of managing a bunch of RDLC files, we manage a ReportEngine class. The ReportEngine class basically generates a bunch of different report types. This is quite advanced, but the results are worth it. Source code to generate a RDLC file with a table: C# or VB.NET.