一、帶報表參數的典型應用。

　　在一個報表中加入參數，最直接的結果就是可以提高查詢語句的重復利用性。如用戶可以通過更改參數來調整顯示的結果等等。對于這些常規的應用筆者不做過多的闡述。筆者現在要說的是，帶參數報表的一些高級應用。

　　參數報表比較高級的應用就是實現報表鉆取。鉆取是改變維的層次，變換分析的粒度。它包括向上鉆取和向下鉆取。向上鉆取是在某一維上將低層次的細節數據概括到高層次的匯總數據，或者減少維數;向下鉆取是指自動生成匯總行的分析方法。簡單的說，現在數據庫中有一張銷售訂單表。根據這張表可以生成一張各個月份的銷售統計表。但是，有可能用戶在查看這張報表的時候，對某個月份的統計結果有懷疑，為此需要查看這個月份的銷售明細。此時如果利用帶參數的報表實現鉆取功能的話，那么就不需要重新查詢或者生成報表。而只需要直接在這張報表上點擊月份，系統就會自動打開另外一張報表。這張報表中的內容就是這月份的銷售明細。從技術的角度講，就是通過參數的傳遞，將這張報表的時間信息作為另一張報表的查詢參數。從而讓系統自動根據這個參數來生成相應的數據，從而簡化用戶的操作。

　　二、帶參數報表要避免注入式攻擊。

　　在使用參數報表的時候，特別需要注意一點就是防止注入式攻擊。注入式攻擊各位讀者或許都了解。可是對于為什么使用參數的報表容易引起注入式攻擊，可能大家并不怎么了解。這主要是因為參數如果采用的是string數據類型所造成的。即如果參數采用的是string數據類型，那么就表示用戶可以根據需要輸入任何類型的字符串。此時如果用戶輸入了一些注入式攻擊的代碼當作參數，則就可能會導致注入式攻擊。為此如果生成報表時，采用的參數時String數據類型的，就需要特別的注意。為了防止這個注入式攻擊，筆者建議如果采用的參數一定要是String數據類型的話，那么最好能夠遵循下面的規則。DB2數據庫與SQLServer數據庫的異同

　　首先，在客戶端將報表查詢語句傳遞給數據庫之前，即將參數復制給Select語句之前，最好進行驗證。即要驗證輸入的參數值中，是否存在一些特殊的符號。這些符號往往跟輸入攻擊有關。如果存在這些特殊字符的話，則需要向用戶提供警告信息，表明存在注入式攻擊的可能性。并且，系統可以拒絕接受這個參數。這個避免注入式攻擊的方法比較消極。如果這些特殊符號確實是查詢參數中包含的內容，那么也無法使用。

　　其次，可以通過值列表的方式來向數據庫傳遞參數。在沒有提供值列表的情況下，如果參數是字符類型的，則系統向用戶顯示的是一個可以使用任何值的文本框。此時數據庫管理員可以使用可用值列表的方式來規范化參數的輸入，限制其輸入一些特殊的字符。也就是說，在定義String類型的參數報表時，讓系統向用戶顯示一個下拉的列表框，然后用戶通過選擇來指定參數。這個操作就跟Excel表格中的下拉列框差不多，用戶只能夠選擇數據庫管理員所提供的值，或者說只能夠選擇某張表中存在的值。由于用戶不能夠自己輸入值，而只能夠選擇，這就可以有效的避免注入式攻擊。不過采用這種方式有一個缺陷，就是如果有效的值太多的話，這個列表就會很長。為此用戶在選擇參數的時候，就會很麻煩。如當有效值有500個的話，那么就需要在500個值中選擇一個值，顯然這有點困難。即使按照參數的名字順序來排列，選擇也是比較麻煩的。大內存SQLServer數據庫的加速劑

　　第三，可以利用列表查詢的方式，來避免注入式攻擊。即當用戶輸入一個參數之后，系統會自動從一個列表中查詢是否存在這個值。如果存在的話，則將這個參數賦值給查詢語句中的變量。如果不存在的話則提醒用戶參數可能輸入錯誤。如現在有一張銷售訂單明細報表。用戶可能需要根據訂單號碼來查詢銷售訂單明細。此時這個訂單號碼就是一個字符型的參數。當用戶輸入這個參數的時候，并不是馬上傳遞給數據庫，這么做太危險，容易產生注入式攻擊。而是前臺應用程序也從后臺數據庫中取得所有的銷售訂單的訂單號碼信息。當用戶輸入參數之后，前臺應用程序會把這個用戶輸入的參數跟自己查詢出來的信息先進行對比。如果有匹配的信息，就將這個參數傳遞給后臺數據庫。如果沒有的話，就向用戶報告錯誤的信息。有些應用程序在設計的時候，還會更進一步。如客戶端程序會先從數據庫中取得訂單號碼與對應的訂單ID。當用戶輸入參數之后，會進行比對。如果比對成功的話，那么客戶端應用程序會將這個訂單號碼對應的訂單ID作為參數傳遞給查詢語句。也就是說，從數據庫服務器角度來講，真正的參數是訂單ID(整數型數據類型)而不是訂單號碼(字符串數據類型)。通過這個數據類型轉換，從而可以從根本上防止注入式的攻擊。

　　以上三種方式都可以很有效的避免注入式攻擊。數據庫管理員需要根據實際應用來選擇合適的解決方案。如當有效值比較少的時候，如按年份來統計銷售訂單時，則可以使用列表的形式。當有效值比較多，特別是這個有效值會自動增長的時候，則可以使用列表查詢的方式。總之一個基本的原則，對于String參數，一定要進行驗證其合法性。否則的話，很容易造成注入式攻擊。

　　三、對于日期型的數據給與特殊的照顧。

　　日期型的數據是數據庫中最容易出現問題的一個數據類型。因為不同語言環境下，如英語與漢語環境下，其采用的日期格式是不同的。如果數據庫中定義了某個日期格式，而輸入的參數如果不符合這個格式的話，則系統就會認為這條記錄不存在，從而在報表中查詢不到相關的數據。為此如果在報表中要使用日期型數據參數的話，將會是一件比較麻煩的事情。所以，在應用程序設計時，數據庫管理員最好提醒前臺應用程序的設計者，能夠規范化日期的格式。如可以要求他們，對于日期型的數據作為參數時，用戶不能夠手工輸入日期。因為不同的用戶輸入習慣不同，如有些人會按年月日的格式輸入(有些用戶會把8月份寫成08，而有些直接寫成8)，有些人則會按月、日、年的格式進行輸入。由于格式不統一，那么數據庫就很難按照同一個規則進行轉換。為此，對于日期型的數據作為參數時，最好在前臺應用程序中能夠規范化輸入的格式。如以一個統計的格式輸入。要做到這一點的話，就可以通過一個日期型的控件來完成。即用戶不能夠手工輸入日期型的數據。當遇到某個參數時日期型的數據時，當鼠標定位到這個文本框，則系統就會彈出一個類似日歷的界面。用戶只有通過選擇日期來輸入日期型的數據，從而規范化用戶的輸入。另外也可以通過掩碼的方式來規范用戶輸入的格式。即預先規定年月日的輸入掩碼。用戶在輸入的時候必須按照這個格式，否則的話，系統不會接受用戶的輸入。這兩種方式都可以實現對日期數據的規范化。

　　當用戶按照同一個格式輸入日期數據后，以后的工作就容易處理了。在將參數傳遞給數據庫的時候，可以在查詢語句中加入一個日期型數據的強制轉換語句。將輸入的日期型數據按照系統表中定義的日期型數據進行轉換。即如果前臺客戶端輸入的日期型數據格式是日、月、年(只要輸入的內容統一即可，沒有具體的要求)，然后在查詢語句中就可以通過數據類型轉換工具對數據類型進行轉換。如將日、月、年表示的字符型數據類型表示會年、月、日的日期型數據類型。如此的話，就可以保證用戶輸入的參數是數據庫可以識別的。就可以避免因為日期格式不一致或者數據類型不一致而導致報表不能夠抓取記錄。