第14章 Reporting Services
我所寫的書中有一些章節重疊了入門篇和高級篇的部分內容。雖然初級和高級內容應該分得很清，但那其實僅限于理想情況：即人人都以同種方式、按同樣順序獲得經驗，并且對初級和高級的定義有統一的認識。
本章中就有一些重疊的內容，已經閱讀過入門篇的讀者會注意到這一點。對于Reporting Services而言，這樣做的原因是多方面的，主要的兩個原因是：
有些人只是出于控制個人報表的目的而進行數據庫開發(在這種情況下，他們幾乎都是直接從Reporting Services開始學起，然后學習用于支持報表中的數據的查詢)。而還有一些人是數據庫"專家"，他們的目的在于使用SQL Server提供的"額外"功能。
這是一項較新的功能(相對于SQL Server這個具有長久生命力的產品而言)，所以它對于許多專業級別的人士來說也是很生疏的。
即使閱讀過入門篇中的"報告"一章，對本章內容也不要匆匆一覽而過。因為盡管這里重復了一些關鍵內容，但是會稍作深入討論，并更著重于介紹真正面向開發人員的內容(而較少關注模型驅動方面的內容)。不過，直接跳至有關數據源和數據源視圖的章節也是可以的，我們將從更為"專業"的角度研究其中的內容，包括參數化、鉆取以及圖表制作。
14.1? 報表服務概述
在完成了所有查詢語句的編寫和存儲過程的運行之后，為使得數據有用，還有一件相當重要的事情要做--使數據對終端用戶可用。
報表是一種看上去極為簡單，實則相當棘手的事物。你不能只是簡單地把數字堆在人們面前。這些數字必須是有意義的，可能的話，還要能夠抓住報表接受者的注意力。要生成實際可用的、有用的報表，需記住以下幾點：
數據的使用量要恰當：一份報表中所列出的數據不能太多，也不能太少。一份充斥了大量數據的報表會令閱讀者迅速失去興趣，并且僅在最初的幾個項生成之后就被棄而不用。同樣，一份言之無物的報表也僅能得到匆匆一瞥，隨即便被毫不猶豫地丟棄。所以，應在恰當的數據和恰當的數據量之間找到一種平衡。
報表要美觀大方：不得不說的是，報表的另一個重要要素就是所謂的"美觀"，也就是說，報表應該做得賞心悅目。難看的報表是沒有人會看的。
在這一章中，我們將介紹Reporting Services(通常也稱作SSRS)的幾個關鍵概念，然后再進一步介紹一些高級內容。雖然略過了一些"基礎"內容，但為了使更高級的內容明白易懂，我們也涉及到了一些必要的基本知識，但接著很快就介紹Report Designer的內容，其涉及Reporting Services提供的最為高級的報表選項。
提示：
出于行文簡潔的考慮(也是為了使重復的內容最少化)，本書對于報表模型僅介紹其作用，而不附具體示例，以此區分初級和高級內容。不過，即使你在閱讀本章之前還不太理解報表模型，也可以通過學習一些核心內容，如數據源和報表設計器，來了解如何使用報表模型器和報表模型設計器。實際報表的構建也是一樣簡單。
14.2? Reporting Services入門
很有可能，你已經生成過一些報表。它們可能是通過打印機打印出來的紙質報表(采用像Access所提供的那樣的初級報表功能，實際上這是我最喜歡的Access的功能之一)。或者你使用了某種相當強大的報表引擎，例如Crystal Reports。即便沒有使用過這些工具，你應該也有過從存儲過程生成簡單(雖然不太美觀)的報表來提交給老板的經歷。我認為這種可能性很大。
但實際情況是，如今的經理和合作者們的期望越來越高。Reporting Services才會應運而生，它實際上有兩種不同的操作：
報表模型(Report Model)：它利用一個相對簡單、Web驅動的接口讓終端用戶自行創建簡單報表。
在Business Intelligence Development Studio中生成報表：這并不意味著一定要編寫代碼(實際上通過拖放功能就可以創建一個相當棒的報表)，而是可根據所需創建更復雜的報表。
注意，雖然用戶最終是可以通過相同的Reporting Services Web主機訪問這些報表，但這些報表是基于不同的體系結構(并且以不同的樣式創建)。
需要補充的是，Reporting Services提供預生成報表的功能(如果構成報表基礎的查詢需要一些時間運行，那么這很有用)，同樣，Reporting Services也提供通過電子郵件分發報表的功能。報表的輸出格式可以是PDF、Excel或Word。
14.2.1? 管理Reporting Services的工具
Reporting Services提供了多種工具幫助創建、使用及管理報表。它們包括：
Reporting Services配置管理器：在SQL Server主文件夾下的"Configuration Tools"子文件夾中可以找到該工具。使用這一工具可以對下列內容進行配置，如Reporting Services的運行帳戶、支持的Web服務器所響應的IP地址和端口、用于Reporting Services的虛擬目錄名、使用的電子郵件帳戶、跟蹤Reporting Services信息的數據庫，以及加密密鑰和可伸縮性配置信息。
Business Intelligence Development Studio(BIDS)：這實質上就是安裝了一套針對Reporting Services、Analytics Integration Services和Data Mining的模板的Visual Studio。如果已經安裝了Visual Studio 2008，那么BIDS也只是添加了一些模板和訪問Visual Studio的快捷方式而已。本書將在后面的多個章節中廣泛使用Development Studio(有時它是以SQL Server的基本安裝形式存在，有時又作為Visual Studio完整安裝的一部分)。
SQL Server Management Studio：在Management Studio中，可以連接到所有和SQL Server相關的服務，以此來管理某個特定的服務。盡管Management Studio中只打包了我認為是功能完全的基本數據引擎，但它仍是執行安全性需求最高的任務和進行作業調度的場所。
Report Server Web站點：在這里實際運行將在Reporting Services中執行的大多數報表，但卻是通過"站點設置"鏈接來進行的(位于瀏覽器的右上方)。這里也可以管理一些服務器的要素(例如緩存、角色分配以及計劃)。
遺憾的是，還沒有單個的工具可以囊括Reporting Services中的所有內容。事實上，上述工具距離這一目標都還相差甚遠(就像Management Studio之于數據庫引擎)。但是，通過組合使用各項工具，可以管理Reporting Services的方方面面。
14.2.2? 訪問Reporting Services的其他方法
Reporting Services同樣也支持一個相當健壯的Web服務模型。通過提供一套庫來支持.NET項目訪問Reporting Services Web Services API。本章末尾將對其基本內容作一個介紹。
14.3? 報表服務器項目
報表模型(在入門篇中是作為Reporting Services的主要內容)僅算是觸及到一些皮毛。Reporting Services的靈活性遠遠不止于此(事實上，有很多專門關于Reporting Services的書籍；其內容相當豐富)。除了報表模型之外，Business Intelligence Development Studio也允許創建報表服務器項目。
前文提到，關于這一主題可以寫一整本書，所以這里將采取的方法是通過一個簡單的示例開始試著了解。然后再稍微做一點擴展。
提示：
在此次發行版本中，報表服務項目的觀感都發生了很大變化。Microsoft購買了Dundas(一家組件開發公司)大量Reporting Services組件的許可。Reporting Services的組件有了重大升級。
在了解報表服務器項目的過程中，將從對報表模型器和報表服務器項目而言都比較常見的幾處關鍵內容開始。如果你已經熟悉了數據源和數據源視圖，那么可以瀏覽下面的兩節，選取與項目示例相關的內容即可，或者也可以直接跳至關于實際報表布局的那一節。
讓我們從一個報表服務器項目開始。首先打開Business Intelligence Development Studio，打開一個新項目。通過Business Intelligence Development Studio中的"報表服務器項目"模板使用商業智能，如圖14-1所示。
?
|
| （點擊查看大圖）圖 14-1 |
注意：
請注意這一對話框的確切外觀將因Visual Studio安裝與否以及具體安裝的語言和模板而有所不同。該圖是Visual Studio的一個完整版本，為的是滿足本書中更高級內容的需求。
這一項目將作為本章中大多數操作要進行的對象。在該項目創建之后，便可以深入到報表的一些關鍵概念。對于已經閱讀過初級內容的人而言，其中的某些概念可以說是一次回顧，但是你也一定想將這首份報表的內容整合起來，使其對隨后出現的更為健壯的示例而言也是可用的。
14.3.1? 數據源
數據源和數據源視圖(這將在后文提到)可能是Reporting Services中最為重要的內容了。無論建立的報表是何種類型，也無論報表是使用報表模型器還是報表項目，這兩項內容都以某種方式發揮著作用。雖然它們的名稱相似，但是在將數據安排進入報表的體系結構中，它們各自服務的層次略有不同。
數據源從本質上講就是對到從中獲取數據的位置的連接的定義。它可以是與一個SQL Server數據源的連接，也可以是與任意OLE DB或ODBC數據源的連接。如果稍稍思考一下這種可能性，那么很快就能得出結論，那就是，雖然Reporting Services與SOL Server相關聯，但是卻可以在報表中使用廣泛的非SOL Server數據源。這確實是一個非常強大的概念。
數據源有兩種類型：
嵌入式：這種類型的數據源儲存在定義報表的同一文件內。在本章后面的內容中將會介紹到XML(稱作報表定義語言或RDL，Report Definition Language)，只需說明所有有關數據源的信息都儲存在報表定義文件下的XML塊中就足夠了。對這種數據源定義的訪問受限于其所嵌入的報表。
共享式：這種類型的數據源和嵌入式大體相同，區別在于這種數據源的定義存儲在其自身文件中(擴展名通常為.ds)。
本章將在后面的內容中使用到共享式數據源。
無論是何種類型，數據源都存儲了多條必須的信息，并且有選擇地存儲了附加選項，以應對可能出現的安全問題。
1. 創建一個數據源
接下來要創建一個數據源，并在本章其后的內容中一直使用它。
如果你的Visual Studio仍是默認設置，那么可以看一下右上方的"解決方案資源管理器"。右擊"共享數據源"，選擇"添加新數據源"，如圖14-2所示。
然后進入"共享數據源屬性"對話框(如圖14-3所示)。
?
|
| 圖14-2 |
?
|
| （點擊查看大圖）圖14-3 |
這個對話框有兩個主要部分，第一部分需要定義名稱(本例中將其命名為將要連接的數據庫名)和數據源的連接字符串(對不熟悉連接字符串的人而言，它的作用是為所有連接到數據源的對象指出路徑和登錄方法)。對連接字符串可以直接編輯，也可以單擊"編輯"按鈕，彈出如圖14-4所示的"連接屬性"對話框。
提示：
當我第一次看到這個對話框時，我微微有些吃驚，因為它與我們在Management Studio中多次使用的連接對話框是不同的；但是，它包含了相同的基本要素，只是在視覺上略有不同(簡而言之，不用為了外觀不同而擔心)。
在本例中，選擇了本地服務器、系統管理員帳戶(sa)以及我們非常熟悉的AdventureWorks2008數據庫。
繼續單擊"確定"，然后單擊"共享數據源屬性"對話框中的"憑據"選項，得到數據源安全選項(見圖14-5)。
?
|
| （點擊查看大圖）圖14-4 |
?
|
| （點擊查看大圖）圖14-5 |
這里有一些選項頗為值得研究--它們包括：
使用Windows身份驗證：顧名思義，這一選項是基于執行報表的用戶來進行身份驗證。這意味著相關的Windows用戶帳戶必須不僅能訪問報表，而且有權訪問和報表相關的所有底層數據。
使用此用戶名和密碼：引用的用戶名和密碼為SQL Server登錄信息(而不是Windows的)。
憑據提示：與上面一樣，這是可預知的。憑據是在運行時從用戶處獲得的。提供的憑據將傳遞給報表所使用的任何數據提供程序。
無憑據：該選項強制匿名訪問，因此數據提供程序應支持這類訪問，否則在運行報表時會出現身份驗證錯誤。
在圖14-5中，我們選擇了sa，并提供了相關密碼。這意味著提供的登錄名和密碼將與數據源一起被永久保存(以加密形式)在ds文件中。
在該對話框中單擊"確定"后，回到較普通的Visual Studio項目，但此時已有了新數據源，開始準備為報表創建更多必須的內容。
14.3.2? 使用報表向導
雖然在創建項目時，沒有選擇報表向導項目類型，但是報表向導中的各部分對報表的創建而言也是可用的。事實上，默認請求一個新報表的簡單方式就是進入報表向導。除非你取消了所有向導創建了一張空白報表，否則，Visual Studio也會嘗試使用該向導來進行一些操作。
繼續看已經建立的示例，這里添加了一個報表以完成報表向導的過程演示。在本例中，假設經理需要一份摘要報表，要求顯示David Campbell在2003年7月完成的所有銷售訂單的銷售總量(按類別分類)。并且經理已事先提醒過她可能晚些時候還要查看其他銷售人員不同時期業績的報表，但是現在她只需要Campbell先生在2003年7月的相關信息。
首先右擊"解決方案資源管理器"中的"報表"節點，選擇"添加新報表"，如圖14-6所示，進入"報表向導"對話框。
單擊"下一步"進入"選擇數據源"對話框，如圖14-7所示。請注意，雖然這里選擇使用的是剛才創建的共享數據源，但也可以在這個對話框中創建一個新數據源(新數據源可以是嵌入式的，但是經過選擇之后，也可以在后面轉換為共享式)。
?
?
|
| 圖14-6 |
?
|
| （點擊查看大圖）圖14-7 |
?
|
| （點擊查看大圖）圖14-8 |
-
SELECT?per.FirstName?+?'?'?+?per.LastName?AS?Employee, ?
-
ps.Name?AS?Subcategory, ?
-
SUM(sod.LineTotal)?AS?Sales, ?
-
soh.SalesOrderID, ?
-
soh.SalesOrderNumber, ?
-
p.Name?AS?Product, ?
-
SUM(sod.OrderQty)?AS?OrderQty, ?
-
sod.UnitPrice, ?
-
pc.Name?AS?Category ?
-
FROM?Sales.SalesOrderHeader?soh ?
-
JOIN?Sales.SalesPerson?SP ?
-
ON?
sp.BusinessEntityID
?=?
soh
.SalesPersonID ?
-
JOIN?Sales.SalesOrderDetail?sod ?
-
ON?
soh.SalesOrderID
?=?
sod
.SalesOrderID ?
-
JOIN?HumanResources.Employee?e ?
-
ON?
soh.SalesPersonID
?=?e.BusinessEntityID ?
-
JOIN?Person.Person?per ?
-
ON?
per.BusinessEntityID
?=?
sp
.BusinessEntityID ?
-
JOIN?Production.Product?p ?
-
ON?
sod.ProductID
?=?
p
.ProductID ?
-
JOIN?Production.ProductSubcategory?ps ?
-
ON?
p.ProductSubcategoryID
?=?
ps
.ProductSubcategoryID ?
-
JOIN?Production.ProductCategory?pc ?
-
ON?
ps.ProductCategoryID
?=?
pc
.ProductCategoryID ?
-
WHERE?(DATEPART(Year,?soh.OrderDate)?=?2003) ?
-
AND?(DATEPART(Month,?soh.OrderDate)?=?7) ?
-
AND?(
soh.SalesPersonID
?=?
283
) ?
-
GROUP?BY?per.FirstName?+?'?'?+?per.LastName, ?
-
DATEPART(Month,?soh.OrderDate), ?
-
soh.SalesOrderID, ?
-
soh.SalesOrderNumber, ?
-
p.Name, ?
-
ps.Name, ?
-
sod.UnitPrice, ?
-
pc.Name?
這個查詢中并沒有什么深奧的內容，它只是把ID號為283的銷售員(也就是David Campbell)在2003年7月的總銷售額收集起來。本章稍后將演示如何使其變得可選，但是現在采用的簡單的、硬編碼查詢。
粘貼這段查詢代碼(可在wrox.com或 www.professionalsql.com 網站上可獲得這一示例代碼)，單擊"下一步"，選擇報表格式是表格式還是矩陣式。表格式報表采用傳統的逐行顯示數據的布局。矩陣式報表查找的是數據的交集，主要顯示行和列的交集的匯總。具體到本例中的報表，這里選擇的是表格式，單擊"下一步"進入圖14-9所示的對話框。
?
|
| （點擊查看大圖）圖14-9 |
生成的銷售報表將顯示出Campbell先生在2003年7月所發出的所有銷售訂單的總和。現在所做的選擇是要讓向導創建我們所需要的格式。選擇SalesOrderNumber作為"組"，選擇Category和Sales字段作為"詳細信息"項，單擊"下一步"。在下一個對話框中(如圖14-10所示)，我選擇了"塊"格式，其中并沒藏著什么玄機，選擇這種格式只是因為我認為它與具體數據最為相配。我還勾選了"包括小計"復選框。因為我們是按SalesOrderNumber進行分組的，所以將會得到一個所有SalesOrderNumber值的總和。
再次單擊"下一步"，選擇一種向導樣式，用它來配置報表。這里選擇"海洋"樣式，不過所有樣式都能正常工作。最后一次單擊"下一步"，得到一個報表摘要，如圖14-11所示，內容包括向導的任務以及為報表名稱(我選擇了SalesOrderSummary，建議你也使用這一名稱，因為在本章的學習過程中，將對報表作出改動)。然后就可以單擊"完成"，生成實際報表。
?
|
| （點擊查看大圖）圖14-10 |
?
|
| （點擊查看大圖）圖14-11 |
第一次出現的報表(如圖14-12所示)看上去并不復雜。
接下來，選擇"預覽"選項卡，預覽包含真實數據的報表外觀(如圖14-13所示)。
?
|
| （點擊查看大圖）圖14-12 |
?
|
| （點擊查看大圖）圖14-13 |
這是一個好的開始，但還有一些重大的缺陷，所以接下來要學習對報表進行編輯。
要編輯報表，需先回到Visual Studio報表中的"設計"選項卡。繼續使用已有的示例，為了使報表看上去清爽整潔，需要注意以下幾個問題：
標題格式盡量恰當得體。
數字值盡量接近貨幣值。
我們要查看每個銷售類別的信息，而不是總和。
下面將逐條討論這些問題。
首先，要更改標題。這是最簡單的一項改動，只要在標題區域內單擊一次選中標題，然后再單擊一次激活光標，就可以像對其他選項卡對象一樣對標題進行編輯。直接雙擊也是可以的。按此操作將標題改為D.Campbell, July 2003 Summary。
接下來，要處理數字格式的問題。這個問題也不復雜。只要右擊存儲Sales信息的字段，選擇"文本框屬性"即可，如圖14-14所示。
打開如圖14-15所示的對話框，該對話框允許對報表表格的單元格(tablix)進行多種屬性設置。在圖14-15中，我選擇了"數字"節點，將數字顯示設置為舍入至最接近的整數貨幣值，并使用千分符。
?
|
| 圖14-14 |
?
|
| （點擊查看大圖）圖14-15 |
提示：
這項操作并沒有詢問使用何種符號作為千分符，也沒有將它假設為逗號。千分符的使用將隨報表服務器的區域配置不同而不同，可針對每一份報表進行覆蓋。
接下來要進入最后也是最難的一項改變：將每個銷售訂單的所有類別進行匯總。首先右擊含有[Sales]值的單元格，如圖14-16所示。選擇"行組"，使用圖14-17所示的對話框修改其屬性。這限制了在更大的SalesOrderNumber組中，每一類別只返回一行(注意tablix最左邊的括號，回憶一下，我們曾在報表向導中選擇添加它)。到這里工作還沒有完成。我們一直把重點放在類別上，但是還應該對類別進行排序使其更具有可讀性。要實現這一點，可以在當前對話框中選擇"排序"節點，如圖14-18所示。
當以上操作都完成后，可以再次預覽報表，發現雖然許多問題都有了顯著改善，但還是存在幾個問題(如圖14-19所示)。
雖然報表逐漸開始變得"美觀"，但在數字方面仍有一些問題。如果將數字與先前返回的值(回到圖14-13)比較一下，很快可以發現數字沒有進行相加。沒錯，報表不會顯示出每一類的總和，而是對每一類別返回第一行。這樣是不行的。
?
|
| （點擊查看大圖）圖14-16 |
?
|
| （點擊查看大圖）圖14-17 |
?
|
| 圖14-18 |
?
|
| （點擊查看大圖）圖14-19 |
?
|
| （點擊查看大圖）圖14-20 |
-
=Fields!Sales.Value?
但是我們需要的是組中該字段的一個總數--或總和。要實現這一點，可使用Reporting Services的一個內置函數。在本例中，使用Sum函數：
-
=Sum(Fields!Sales.Value)?
要看到它在對話框中的樣子，參見圖14-21。
單擊"確定"，再次預覽報表，現在得到了一份格式基本良好的報表(不要在格式上過度要求--目前只是剛剛開始報表的學習)，如圖14-22所示，并且已經可以準備運行，打印輸出(或輸出為另一格式)并送達經理處。
?
|
| （點擊查看大圖）圖14-21 |
?
|
| （點擊查看大圖）圖14-22 |
14.3.4? 參數化報表
關于David Campbell的這份報表做得很好，但是有很大局限性。回想之前，經理曾經提醒過她將會在晚些時候查看其他銷售人員在其他時間內的相關信息。這便要求報表實現這一功能。
對于大多數報表項目來說，參數化都是至關重要的一個部分。所幸讓SQL Server對參數化的報表進行識別還相對容易些。一旦報表被參數化，SQL Server就會以某種方式提示用戶提供一個參數值。本節將介紹許多使用戶進行參數選擇變得更為簡單的選項。
第一步，要將最基本的參數化添加至報表中。要使報表依賴于參數，首先要將查詢語句改為需要參數。然后只需通知報表在執行之前請求獲取參數。下面先來編輯查詢。進入項目中"視圖"菜單下的"報表數據"項(在"解決方案資源管理器"面板中顯示為一個選項卡形式)。"報表數據"選項卡如圖14-23所示。雙擊報表中的數據集，彈出如圖14-24所示的對話框，該對話框允許對查詢進行編輯(有些報表有多個數據集。這里的報表只有一個)。
?
|
| 圖14-23 |
?
|
| （點擊查看大圖）圖14-24 |
提示：
也可以右擊數據集，選擇"查詢"，在一個單獨的查詢編輯器窗口中編輯查詢。
這里已經將Darren Campbell的BusinessEntityID、7月和2003年這些硬編碼值改為參數值(分別為@BusinessEntityID、@Month和@Year)。完成之后，可以進入顯示參數選項的對話框，如圖14-25所示。
由于已在該對話框中添加了每一個參數，所以這里可以直接單擊"確定"，準備預覽(或直接運行)報表。在圖14-26中，通過"預覽"選項卡運行了報表。請注意在面板頂部它是如何要求提供(這里已經提供)這三個參數的。
在瀏覽報表的過程中，可以發現雖然它是以和原始報表中完全一樣的值而告終，但是現在卻能夠針對某一時間段或某一銷售代表來運行報表。報表開始逐漸更趨靈活。
?
|
| （點擊查看大圖）圖14-25 |
?
|
| （點擊查看大圖）圖14-26 |
14.3.5? 提供參數值并控制其使用（1）
目前生成的報表看起來相當不錯。現在不能再像之前那樣僅提供一份關于David Campbell的報表了，而是能在報表中輸入不同參數，包括不同雇員的BusinessEntityID和完全不同的時間段。但是，在報表的使用方面，仍然還有一些問題，其中包括：
輸入值的格式為任意形式，意味著用戶可能輸入非法值。
對于何種輸入值為合適的這一問題沒有任何提示，用戶要么知道，要么憑借猜測。這對于日期和年份來說不是什么太大問題，但是對于獲得正確的銷售人員的BusinessEntityID來說就會造成困難。
無論輸入哪一位銷售人員，報表頭都被硬編碼為David Campbell。月份和年份也存在類似的問題。
下面看一下如何解決這些問題。
1. 創建預設的參數表
Reporting Services擁有為參數創建預定義值列表的能力。該功能運用已定義的參數，并對其添加附加屬性。
要將固定列表添加至@Month和@Year參數中，需導航至"報表數據"選項卡下的"參數"節點，展開列表，雙擊需要賦值的參數(也可以右擊參數，選擇"參數屬性")。對@Month參數進行上述操作，彈出如圖14-27所示的對話框。
注意這里可以為參數設置一個自定義的提示(不一定為參數名)。還可以控制參數的初始可見性(有可能某一參數只有當另一參數設為一個特定值時才為有效)以及是否允許可空值或空白值。
這里保留了大部分的默認設置，但是將數據類型改成了整型(記住，我們將月份的數字作為了一項參數)。下面就可以進入如圖14-28所示的顯示"可用值"節點的對話框。
?
|
| （點擊查看大圖）圖14-27 |
?
|
| （點擊查看大圖）圖14-28 |
在這個對話框中，我作了許多修改--最明顯的是提供了單獨的標簽和值。標簽為用戶顯示出可供選擇的項，值則是指報表在執行時將要傳遞給參數的內容。通過選擇"指定值"單選按鈕，可以創建這一列表。但是請注意，這一列表也可以是查詢驅動的(稍后將作介紹)。
繼續轉到"默認值"節點，可以發現這里允許提供一個默認值(在圖14-29中，選擇的值是一直在使用的7)。
最后，切換到"高級"節點(如圖14-30所示)，如果用戶改變參數值，這里給出了報表數據將選擇在何時作出相應改變的選項。我們可以強制始終刷新，可以要求用戶明確提出刷新，也可以讓SQL Server來決定恰當的刷新時機。
?
|
| （點擊查看大圖）圖14-29 |
?
|
| （點擊查看大圖）圖14-30 |
接下來你可以自己嘗試一下將參數@Year的數據類型設置為整數型，默認值為2003。然后就可以再次預覽或運行報表，查看所做改動的效果，如圖14-31所示。
雖然在BusinessEntityID和Year這兩個參數中沒有發現顯著的不同，但可以很快注意到現在的Month已變成一張下拉列表，即使月份的參數實際使用的是整數值，該列表也可以為每個月份提供名稱。還可以測試一下在year字段中輸入文本。SQL Server會相對得體地指出類型不匹配的問題(雖然并不是以一種最完美的方式，但總比爆滿屏幕的錯誤要好得多)。
?
|
| （點擊查看大圖）圖14-31 |
14.3.5? 提供參數值并控制其使用（2）
2. 通過查詢創建參數表
為參數@BusinessEntityID提供一個預先填充的列表要比其他兩個參數難一些。雖然可以像@Month一樣創建一個固定列表，但那意味著只要銷售人員的列表發生變動，就必須隨時編輯報表。月份比較穩定，但是銷售人員的變動頻率卻很高。每時每刻地編輯報表是不現實的，尤其是當銷售人員的信息已被輸入到系統的其他地方時。
要啟動上述任務，首先需要創建一個新的數據集。首先右擊"報表數據"選項卡中的數據源，選擇"添加數據集"，如圖14-32所示。
彈出如圖14-33所示的對話框。
?
|
| 圖14-32 |
?
|
| （點擊查看大圖）圖14-33 |
-
SELECT?p.BusinessEntityID,?p.LastName?+?',?'?+?p.FirstName ?
-
FROM?Person.Person?p ?
-
JOIN?Sales.SalesPerson?sp ?
-
ON?
p.BusinessEntityID
?=?
sp
.BusinessEntityID;?
繼續進入"字段"節點，如圖14-34所示。該對話框允許在使用該數據集的所有報表中選擇返回字段的名稱(以便進行訪問)。這里選擇默認名稱，即使已經選擇，也可以在結果中改變名稱。單擊"確定"，數據集便創建成功。現在可以使用它對參數列表進行布局。
?
|
| （點擊查看大圖）圖14-34 |
?
|
| （點擊查看大圖）圖14-35 |
?
|
| （點擊查看大圖）圖14-36 |
這樣一來，參數默認值和數據類型便被迅速設置恰當。剩下來要做的就是處理固定表頭的問題。
3. 通過參數獲取表頭和其他字段
通過編輯文本框來使用參數值相對簡單。首先選中擁有現有固定值的文本框，進入編輯模式。要使其變為動態的，需要結合多個項。首先，要為動態值提供一個前綴，這里使用"Summary for："。然后再次右擊，選擇"創建占位符"，進入如圖14-37所示的對話框。占位符使得Reporting Services可以對文字文本和功能代碼進行區分。注意，"值"字段有一個下拉框，將其展開可以在大量的動態值間進行選擇。本例中為用戶選擇的某一個參數提供了一個參考值。繼續并單擊"確定"，可預覽或運行報表查看效果(如圖14-38所示)。
?
|
| （點擊查看大圖）圖14-37 |
?
|
| （點擊查看大圖）圖14-38 |
?
|
| （點擊查看大圖）圖14-39 |
?
|
| （點擊查看大圖）圖14-40 |
14.3.6? 添加圖表
Reporting Services還支持圖表對象。圖表是一種功能較為強大的事物，因為它在很大程度上使得報表不僅僅是一份報告來源，而且還能夠進行更真實的分析。下面要為報表添加一張圖表，為本月各類產品的銷售情況提供一個可視化表示形式。
首先打開Visual Studio的工具箱，將Chart對象拖入報表中(這里將它放在tablix的右邊)。這將進入如圖14-41所示的對話框，并允許在大量的圖表類型中進行選擇。
考慮到我們并沒有太多類別可供選擇，因此決定使用3D形式的餅型圖表(如圖14-41所示)。可將"報表數據"選項卡中的數據集內的字段直接拖入圖表中的特殊接收區域(如圖14-42所示)。我將Sales字段由Dataset1拖至"將數據字段拖至此處"區域，又將Categories字段拖入"將類別字段拖至此處"區域。
?
|
| （點擊查看大圖）圖14-41 |
?
|
| （點擊查看大圖）圖14-42 |
?
|
| （點擊查看大圖）圖14-43 |
這樣，我們便迅速擁有了一張提供tablix數字的可視化表示的基本圖表。
提示：
兩個對象間不存在相互關聯。它們只是碰巧使用了相同的數據集，而并不是被要求這樣做的。事實上，在報表建立的大部分過程中，都沒有使用圖表，如果愿意，也可以刪除tablix，而只保留圖表。
?
14.3.7? 鏈接報表
Reporting Services允許對多個報表進行鏈接，既可以向下鉆取到更深層的細節，也可以鉆取到完全不同的報表中。
鏈接過程由一系列"操作"支持。操作支持內部的(其他報表)和外部的(如一個網站)鏈接。
下面要為本章中所使用的報表添加最后一個要素。要利用這個鏈接，需要下載(你可能還沒有下載)本書的代碼，找到預先創建的SalesOrderDetail.rdl文件。可以通過右擊"解決方案資源管理器"中的"報表"，選擇"添加">"現有項"，將該文件添加到項目當中。
要使用這一新的Sales Order Detail報表，需要對報表中含有Sales Order Number的文本框屬性進行編輯，然后訪問"操作"設置，如圖14-44所示。
一旦將SalesOrderDetail.rdl文件適當地添加到了項目中，并對圖14-44所示的Sales OrderNumber操作進行了設置之后，就可以最后一次運行或預覽摘要報表了。現在單擊David Campbell在2003年7月的第一個Sales Order Number，就可以得到如圖14-45所示的Sales Order Detail報表。
?
|
| （點擊查看大圖）圖14-44 |
?
|
| （點擊查看大圖）圖14-45 |
剩下來要做的事就是對報表進行部署。在"解決方案資源管理器"中右擊報表，選擇"部署"。但是這里還有個小問題要注意--需要在項目定義中對部署的目標進行定義。
(1) 右擊報表服務器項目，選擇"屬性"。
(2) 在TargetReportFolder字段中，設置登錄到報表管理器時想駐留報表的文件夾。
(3) 在TargetServerURL字段中，輸入報表服務器的URL。在本例中，該URL很簡單，為 http://localhost/ReportServer ，但服務器名可以是有權限對其進行部署的任一服務器(如果在安裝時作了定義，那除Report Server外，還可用Virtual Directory)。
部署完成之后(通過右擊項目選擇"部署")，便可以查看報表。導航到報表服務器(如果是在本地主機上并使用默認目錄，則地址為 http://localhost/Reports )。單擊報表文件夾，選擇SalesOrderSummary報表。
首次加載報表可能需要一些時間，你所見到的報表和我們在項目中所定義的一樣(如果回頭再次導航一下，報表定義將被緩存，加載速度就會變得相當之快)。
14.4? 有關RDL的簡注
RDL全稱為Report Definition Language--是一種基于XML的報表定義語言。在本章中我們對報表所做的所有改動都經由Visual Studio轉換成了RDL。如果想查看報表項目的RDL，可右擊報表選擇"查看代碼"。下面是我為本章所創建的一個示例報表的一段摘錄。它定義了為銷售人員的參數提供值的數據集。
-
<
DataSet
?
Name
=
"SalesStaff"
>
?
-
<
Fields
>
?
-
<
Field
?
Name
=
"BusinessEntityID"
>
?
-
<
DataField
>
BusinessEntityID
</
DataField
>
?
-
<
rd:TypeName
>
System.Int32
</
rd:TypeName
>
?
-
</
Field
>
?
-
<
Field
?
Name
=
"Name"
>
?
-
<
DataField
>
Name
</
DataField
>
?
-
<
rd:TypeName
>
System.String
</
rd:TypeName
>
?
-
</
Field
>
?
-
</
Fields
>
?
-
<
Query
>
?
-
<
DataSourceName
>
AdventureWorks2008
</
DataSourceName
>
?
-
<
CommandText
>
SELECT?p.BusinessEntityID,?
p.LastName?+?',?'?+?p.FirstName?AS?Name ?
-
FROM?Person.Person?p ?
-
JOIN?Sales.SalesPerson?sp ?
-
ON?
p.BusinessEntityID
?=?
sp
.BusinessEntityID;
</
CommandText
>
?
-
<
rd:UseGenericDesigner
>
true
</
rd:UseGenericDesigner
>
?
-
</
Query
>
?
-
</
DataSet
>
?
可以直接修改RDL (但是要小心。如果在直接編輯時引入了一個錯誤，那么要找出到底錯在哪里將會十分困難)。
14.5? 小結
Reporting Services對許多SQL Server的安裝而言都有重要影響。對許多公司而言，在中央數據倉庫中內置一個相對強大的報表服務器是一種解放，使得向數據使用者散布信息變得更為簡單。對另一些組織而言，Reporting Services提供的解決方案足以替代長期以來所使用的報表包，如Crystal Reports。SQL Server 2008添加了一些新的功能和控件，使得報表更為精致和強大，引擎也經過了重新設計，可伸縮性更高。
盡管本章中所使用的報表較為可靠，但也只是我們初嘗到的一點甜頭。報表可以被參數化，可以嵌入圖表，可以與其他產品整合(如Microsoft Sharepoint Services或Microsoft Office Sharepoint Services)、可以從一個報表鉆取到另一個報表，甚至可以在報表中再嵌入其他報表。
要了解報表的更多內容，建議閱讀有關Reporting Services的專門書籍。
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
