在SSRS 2005中處理非常高的文本框和分頁

Question

我在SQL Server Reporting Services 2005中有一個報表。它使用頁眉和頁腳，並且沒有子報表。主體部分包含一些較小的元素，然後是一個簡單的單列表格。該表具有單個標題行和單個詳細信息行。標題基本上就是一個標籤。詳細信息行是一個帶有簡單的Fields！FieldName.Value作爲其輸出的單個文本框。

問題是FieldName在這種情況下是一個高度可變長度的字符串。它可以是一個8000個字符的句子（通常不超過2頁）。文本可以包含行/分段符（返回），但不包含其他特殊格式。只要內容適合在一個頁面上，一切都很好。一旦文本超出了單個頁面（8.5x11），文本就會非常快速地被截斷。由於這是分頁問題，​​因此只有在導出爲PDF或在「打印版式」中查看報表時纔可見。

看起來好像該行可以在第一頁上增長到最大大小，然後它將它截斷並在第二頁上啓動它。但是這個截止日期並沒有經過仔細的文字處理。它可以在一行中間出現，使其顯示第一頁上的字母的前半部分和第二頁頂部的下半部分。

顯然，這是不可接受的，因爲它看起來非常不專業，並且可能會削弱如此混亂分裂的線條的可讀性。我也永遠無法確定它會分裂得厲害，因爲有時它或多或少會均勻地結束頁面，儘管通常我仍然可以在下一頁看到某些字母的懸掛尾巴（例如g和p）。

第二個問題是我真的很喜歡錶格行標題在每個頁面上重複。設置顯而易見的屬性「RepeatOnNewPage」不起作用。我懷疑這是因爲它仍然試圖展示一個真正垂直高的行。似乎可以重複標題並在詳細信息行之間很好地分割頁面。但是，因爲這基本上只是一大塊文本，因此只有一個很高的行，它不會很好地分割它。

我能做些什麼或用什麼來解決這個問題？只要它不會在一行中間切斷文本，我就可以不用重複標題。

Answer 1

最後，截斷文本問題是由於相關文本框中的非標準填充。

無論出於何種原因，填充大於默認值（2pt左右）似乎會導致其分頁變差。我想這是由於算法在決定何處打破段落時未考慮填充。使用默認填充，該行總是在每個頁面上乾淨利落地結束。

作爲一種解決方法（因爲我喜歡填充給佈局的額外空白空間），所以我使用了一個矩形來實現邊框並使其內部的文本框比矩形小八分之一英寸。這給了盒子一些內部填充，同時顯然允許分頁正確地確定何時分解線。

不過，很多不必要的頭痛。

Answer 2

不幸的是，分頁微調是SSRS最大的弱點之一。

我只能建議您在SSRS獲得它之前將長文本分成多行。你想要解析文本來尋找分詞。結果將是輸出中看起來奇怪的中斷，因爲您不知道打印報告中哪一行會出現中斷。但是，它比將文本減半的可讀性要高得多。

如果文本包含合理大小的段落，則可以將其解析出來。

甚至可以使用SQLCLR和System.Drawing.Graphics.MeasureString方法來測量文本來微調輸出，但我不會推薦該路線作爲心臟的佯攻。

Answer 3

我已經完成了JC在過去提出的建議，我已經將文本分解爲段落，每個段落實際上都是它自己的行。鑑於SSRS的侷限性，它工作得很好。

有一點需要注意的是，你需要確保你的段落正確排序。在大多數情況下，它會按照正確的順序顯示它們，但是在具有sortID的列中添加一些排序提示可能是一個好主意。

Answer 4

在SSRS 2008 R2和Visual Studio 2008：

點擊（未右擊）一個文本框，然後轉到屬性窗口（VS的右下側） - >同頁=假。

文本將在一行之間切換並在下一頁繼續。

只是想在這裏添加搜索這不會返回很多結果。