I have a report in SQL Server Reporting Services 2005. It makes use of a page header and footer and has no subreports. The body portion contains a few smaller elements and then a simple single column table. The table has a single header row and a single detail row. The header is just a label, basically. The detail row is a single textbox with a simple Fields!FieldName.Value as its output.
The problem is that FieldName, in this case, is a highly variable length string. It can be a sentence up to 8000 characters (usually no more than 2 pages worth). The text can contain line/paragraph breaks (returns) but no other special formatting. Everything is fine so long as the content fits on one page. Once the text exceeds a single page (8.5x11), the text is very nastily cut off abruptly. Since this is a pagination problem, it is only visible when exporting to PDF or when viewing the report in Print Layout.
It seems as though there is a maximum size the row can grow to on the first page and then it chops it off and starts it up on the second. But this cutoff is not carefully managed in relation to the text. It can occur right in the middle of a line, causing it to show the top halves of the letters on the first page and the bottom halves at the top of the second page.
Obviously, this is unacceptable, as it looks very unprofessional and can impair the readability of the line that was so messily split. I also can never be sure it'll split badly, as sometimes it more or less ends the page evenly, though usually I can still see the hanging tails of certain letters on the next page (g and p for instance).
The secondary problem is that I'd really like the table row header to repeat on each page. Setting the obvious property, "RepeatOnNewPage" has no effect. I suspect this is because it's still trying to show the single really vertically tall row. It seems like it's okay repeating headers and splitting pages nicely between detail rows. But because this is basically just a big block of text, and thus just one really tall row, it doesn't split it nicely.
What can I do or use to solve this problem? I can live without the repeating header so long as it just doesn't cut off text in the middle of a line.
Unfortunately, page break fine tuning is one of the biggest weak points of SSRS.
I can only suggest that you break up the long text into multiple rows before SSRS ever gets it. You'd want to parse the text to look for word breaks. The result will be odd looking breaks in the output since you won't know where the break will come on a line in the printed report. However, it'd be much more readable than cutting text in half.
If the text is comprised of reasonably sized paragraphs, you could parse it out that way instead.
You might even go so far as to measure the text using SQLCLR and the System.Drawing.Graphics.MeasureString method to fine tune the output but I wouldn't recommend that route for the feint of heart.
In SSRS 2008 R2 and Visual Studio 2008:
Click (not-right click) a textbox and go to the properties window (lower right side of VS) -> KeepTogether = false.
The text will cleanly cut between a line and continue on the next page.
Just thought to add here as searching for this doesn't return many results.
I have done what JC has suggested in the past where I've broken down the text into paragraphs and each paragraph would in effect be its own row. Works pretty well given the limitations of SSRS.
One thing to be careful about is that you would need to make sure that your paragraphs sort properly. In most cases it would display them in the correct order, but adding in a column with sortID to give some sorting hints to the table would probably be a good idea.
In the end, the cut-off-text problem was due to non-standard padding on the textbox in question.
For whatever reason, having padding any greater than the defaults (2pt all around) seemed to cause its pagination to go sour. I imagine it is due to the algorithm not taking padding into consideration when deciding where to break the paragraph. With default padding, the line always ends cleanly and nicely on each page.
As a workaround (since I liked the extra white space the padding gave to the layout), I used a rectangle to achieve the border and made the textbox inside it smaller than the rectangle by about an eighth of an inch. This gave the box some inner padding while still apparently allowing the pagination to correctly determine when to break up lines.
Still, a lot of unnecessary headache.
Related
I have some text I want to keep "atomic" within a report header. The text in question is the "Period Ending Date: 1/15/1998". It is OK if that block of text wraps down below, but I would like to keep the whole block of text together on one line. This has to be dynamic however, as the text will grow and shrink dynamically--sometimes the server and database and company name will be short and everything fits on one row, sometimes long even the database name will need to wrap.
And this is how I have it defined in the expression
Is keeping it "atomic" possible?
As the comments say you basically have two options, either make the text box wide enough to fit any possible combination of company, server, database and end date that could occur - you can use max(len([your fields])) in SQL to determine the maximum possible characters and then figure out the width from your font information - or you can put the separate chunks of information into separate text boxes and arrange them however is most aesthetically pleasing to you. Personally I'd have a company name box on one line, the Server and database beneath it and the end date beneath that. Up to your preference though obviously.
#Jeff.Clark, I guess you need to rethink the design. I agree with #Viking's comment. As far as i know, what you are trying to achieve is not possible in SSRS (keeping the Can Grow = False) and want to wrap it on the field level not the word level. I tried using it in the placeholder but it is splitting the field.
However, if your requirements are very critical and no matter what you have to do it in this way then i think you can achieve it by determining maximum characters the cell can accommodate in one line and then subtracting the SUM of LENGTH of the the fields+ the text(ex: "Totals per payroll period") and find out a position in your string to insert VBCRLF so the rest of the data will go to next line. Without the original expression i will not be able to provide the accurate updated expression but it will be nested IIFs to get the position of VBCRLF. I personally do not prefer this method because it will take lot of processing on the report design level and can affect the overall performance of the report as well as not very pretty when it comes to the maintenance of the report.
I've not come across anything like I am looking for so either I'm either not asking the right questions (for which I will apologize for re-asking a question) or it's not been asked.
I'm working on a report to print header information onto pre-printed carbon copy forms on a continuous form feed impact printer. The form is two pages and the header for the second page only contains part of the information that the header on the first page has.
I have the first page header working fine. I played with using rectangles and it was printing on target on every other page. The problem comes in when I try to print the page two header.
The way I am formatting the headers is that I have a single cell tablix with a rectangle in the cell. I've measured out where the 11 fields belong for page one of the form and placed them on the form. This all works correctly. Below that, I've inserted a second rectangle with the add page break before property checked. In that rectangle I have two of the fields that are repeated one just above the other (field 1 and field 2). Field 1 is in exactly the same spot as it is on page one. Field 2 is higher and to the left of where it is positioned on page one. The report body has no margins. Positioning is all done directly through the elements themselves. Field 1 sits about 1/16 to 1/8 inch lower than it does on page 1 even when position top is set to 0 (and there is no page margin). I can position field 2 exactly where I want it to be however. If I have multiple forms print out, all the page ones are perfect and page 2 field 2 is spot on but page 2 field 1 is always too low.
I tried separating the rectangles but was unable to connect the dataset to the second rectangle.
Is there a better way to do this? Is there a setting I'm missing that is adding padding to the second rectangle? Any help is appreciated.
Not quite the answer that I was looking for but it nearly fixed the problem. It turns out that the field itself had padding on it. I'm not sure how as I copied and pasted it from the first page but it moved it up to a acceptable position. It is still a bit low but close enough that the requester is happy with it.
I work with ssrs with a dynamic row data in matrix/tablix. There is possibility when I have more than one page (say it two pages) where the data just fill half of the second page and leave a blank space below (half page blank space on the second page). How is the way to fill this blank space with empty rows? (whether rendering empty rows in the tablix, or inserting background image, or anything. I don't have any solution yet as it is dynamic data with many possibilities of the blank space size on the page)
Unfortunately there aren't any settings in the reporter that support this behavior. There are however several workarounds you could use to get the wanted result.
[1]
You could determine the amount of rows that fit on the first page and on the second page, just in case you have items above the
table on the first page. Before you send the datasource to the
reporter count the total rows and check if it exceeds the first page.
Then calculate the number of rows missing to fill an entire second
page (or third/fourth... if you ever get more data). Finally you add
empty rows/objects at the end of your datasource, which will of cource
cause the pages to be filled to the end.
As was pointed out before, this solution is only possible when working
with fixed row heights. If certain columns can have multi-line cells
then these could be checked as well and taken in account when
calculating the number of rows being displayed on the page. This makes
it slightly more complicated but is still a valid solution if you can
predict which columns might be troublesome.
[2]
A second solution would be to hide the table borders and place the table inside a rectangle that spans the maximum size of the
page. The borders of this rectangle can be used to display the table
outer borders and columns can be displayed by adding lines inside the
rectangle. This will cause the columns to fill the last page of the
report automatically. Unfortunately this isn't a solution to display
horizontal grid lines.
[3]
A third approach is adding an extra table directly below your table
with the same size of columns. Using the same method as from the first
solution you could fill the second table to represent the empty rows.
You'll probably have the same issue as with the first solution when
dealing with multi-line rows though.
I believe solution [1] and [3] will offer the most exact solution, if you're willing to do the math. If you don't want any horizontal lines then I suggest using approach [2].
Using an image to overlay the borders is of course another option but then you'll have the same issues when dealing with the multi-line rows. If you plan on working with fixed row heights, where you leave space for multi-line cells then this is becomes a valid approach but so does solutions [1] and [3].
Update:
If you only need the filled pages for printing you could make sure you add enough empty rows to fill at least the entire last page, these may go to a new page (1 new page, not 2... you can use a simple calculated guess for this) and exclude the last page when printing.
I have a report with a bunch of controls in the Detail section.
I am working off a word document that was given to me as a sample and I recreated it in access almost perfectly. What I need now is a way to handle overflowing the text boxes. I have "Can Grow" enabled, but here is the real issue:
I have a fake table going on. Multiple text boxes arranged in a way that just doesn't work in a subform. Certain cells have red, green or yellow backgrounds while others are just plain white. When one of the text fields overflows, and "grows", the other text boxes in the same row stay the same size as before and it looks very very odd (703 twips vs 300). I would really just love for it to work as if it were a table in word/excel and the entire row would grow at once (all =703 twips), but seeing as how it isn't literally a "row" I just want a way to associate the height of these text boxes with each other.
Is anything like this possible? If I need to clarify anything just let me know, I hope I've given ample information.
In the design view of your report select all the textbox controls in the detail section and all the labels in the page header section. Right click on one of the textbox controls and select Layout -> Tabular. The controls and labels should now align with each other.
You've not set which version of Access you're using but this works in Access 2007.
Ok here we go. So I had a fake table, I needed it to have table borders around each text box and when one text box got taller than the others in the row, the borders would look totally wrong. So, what we have to do is literally draw on the report at runtime, which can be done in any view including print preview. This code must be placed in the Print event
'step one. find out which box in the row has the greatest height value.
'You can come across this information however you want.
'It will likely depend on what data goes in the boxes.
'For the sake of the answer length we will skip that actual code
'step two. Take measurements and store them in variables.
'You will need a start point, and an end point in standard (x1,y1),(x2,y2) form.
Dim t As Integer 'top
Dim l As Integer 'left
Dim b As Integer 'bottom
'step three. Use these measurements and draw your lines.
'Try to use looping if your naming and report layout work will allow it.
Me.Line (l, t)-(l, b), RGB(0, 0, 0)
' (x1,y1)(x2,y2),pick a color
'We just drew a line straight down the length of the control
'If you plan ahead, and place a line on the report permanently on top of the first row
'and below every row, you will only need to draw vertical lines.
'The lines below each row will be pushed down by the tallest control
I hope this helps. I had no idea this stuff existed before at all. Here is the MSDN info about it: http://msdn.microsoft.com/en-us/library/aa221362%28v=office.11%29.aspx
OK...
1 - Go into Design view of your report
2 - Select ALL the textbox controls in the detail section that you want to be table like and ALL grow if any one grows.
3 - Right click on one of the selected textbox controls and select Layout -> Tabular.... but... now... after you have your textbox row controls as a tabular layout... You must do one thing more...
4 - Inside your reports FORMAT TAB properties... Set ALL PADDING properties to 0.00... 0.00 for Top Padding, 0.00 Right Padding, 0.00 Left Padding and 0.00 Bottom Padding. (default is usually around 0.0208)
5 - Please note that changing your textboxes to a Tabular Layout kinda throws your textboxes to the right (at least for me) so you may need to re-adjust them so they are aligned with your Page Header textboxes again (if you have any that you might be using to header name your table like columns).
6 - Make sure ALL SPACE is removed in the detail area by having the bottom bar (page or report footer) snugly up against the bottom of your Tabular Textbox Layout and also ditto with the upper detail bar (page or report header).
7 - Now when you look your report in print preview with max 200% or more zoom you WILL still see very very minor spaces between your cells in your layout but when you actually print they will be almost unnoticeable unless you take out a magnifying lens.
I found a solution for my situation but I would like to have a better one...
In my case, a TextBox at the left side is describing the content of 1 to 3 pictures on the right side. The TextBox, if enlarging more than the height of the first picture, would shift pictures 2 and 3 down, in spite of a properly designed Top-Attribute in the picture controls.
My solution: I put the height attribute of the text box to 15cm (e.g 2 Inch) and enable it as shrinkable.
However, strange, but this helps for positioning the Pictures at its desired Top-Locations... :-) as well as minimizing the horizontal space used.
I'm new on this particular project, and I've been tasked with resolving an issue that's appearing in IE8.
If you check http://funds.ft.com/ETFHomepage.aspx, There's a section called "News". In that section, there's a column called "Most Popular ETFs". This should be the same width as the "Recently Viewed ETFs" column.
For reference, this page is appearing correctly in Firefox. Can somebody please point out what I can do with CSS or (some other means)* to resolve this?
*I know the best way to resolve this issue is to scrap the terrible design and implement it correctly!! :-) -- we're actually doing that right now. It's a big job, so it's taking a long time. In the mean time however, we have to fix the bugs as they appear. Thanks
Update: just to note what I've said to Hristo, "I think the problem is with the table (rather, nested tables) on the left. The table in the center has its width defined by the image, and the table on the right doesn't have an image so it gets crushed"
Well the reason this is happening is because of the url you have under the "Alphaville: Overcoming the Volcker rule, with ETFs" header. Since the url has no whitespace in it, the table tries to give it space. So there are a couple of ways to fix this problem:
Plain text urls aren't very becoming on a webpage (especially when they're not in anchor tags so you can click on them.) Could you update the content so that you don't have a raw url in your content?
If you must be able to handle long lines of text with no whitespace then you need to figure out how to change the layout of the page so it forces the text to either wrap or clip to fit the container. Try playing around with putting "table-layout: fixed" on your tables to force the column widths to be sized based on the table's specifications only (instead of content). Firefox seems to be wrapping on dashes and slashes in the url whereas IE only wants to wrap on the dashes in the url.
I would say your layout is fine, and you just need to fix the content generation so it doesn't include any long plain text urls (option 1 above)
EDIT: If you do decide to go with option 2 above, then look into the css rule "word-break: break-all". It is IE only and it forces the text to break as soon as it reaches the end of the container. Not good for words, but it works for url's. So you couldn't apply this to the whole news table, but you could to just the cell that contains the url.