2008-10-04 86 views
2

我目前正在使用的應用程序會生成大量的SQL內嵌查詢。所有生成的SQL然後被交給數據庫執行類。我想寫的數據執行類解析服務,將採取這樣的查詢:解析T-SQL以參數化查詢

SELECT field1, field2, field3 FROM tablename WHERE foo=1 AND bar="baz" 

,並把它變成是這樣的:

SELECT field1, field2, field3 FROM tablename WHERE [email protected] AND [email protected] blah blah blah 

已經寫任何東西,這將做到這一點對於我在c#或vb.net?這是重構此項目的DAL之前的停止空缺。

更新:夥計們我有一個巨大的應用程序,從傳統的ASP移植到ASP.NET與成千上萬的行內嵌SQL。唯一的優點是所有生成的sql都被交給了一個數據執行類。我想在執行之前捕獲sql並將它們動態地參數化,作爲重寫整個應用程序的停止空白。

回答

2

現在重構。

如果你認爲這個抽象層將能夠更快更容易地出現,那麼你就是在愚弄自己。內心深處,你知道它會增加項目的風險和不確定性,但是你想要殺死SQL注入問題或者你用魔法彈擊的任何問題。

爲了編寫這個新的分析子系統和迴歸測試系統,您可能會用數據庫中相對較少的代碼生成和測試的SP來調用所有內聯代碼。另外你可以一塊一塊做。

爲什麼要構建一個重要的一次性代碼,這將很難調試,並且不是真正與您想要的最終體系結構內聯?

3

不要這樣做。這是太多的工作。另外,這種方法存在大量安全風險。

至少查看Command對象和參數化查詢。

Here is a small tutorial.

+0

請閱讀整個問題,我試圖在查詢之前參數化查詢,而不必重寫數千行代碼。 – NotMyself 2008-10-04 20:10:01

0

我會第二的建議,使用命令參數做你想做什麼。 任何類型的SQL查詢字符串解析只是要求有人與你一起玩SQL注入遊戲。示例代碼如下。參數收集很容易在正常的方式

command.CommandText = "SELECT * FROM table WHERE key_field='?'" 
command.Parameters.Append command.CreateParameter(, 8, , , "value") '8 is adBSTR value 
set rsTemp = command.Execute 
0

Ø認爲你的任務是太多honerous ... 你應該建立一個非常強大的解析器來操縱......我認爲這是更好,更容易開始重寫應用程序,找到生成查詢的點和重構代碼。

好Loock!

0

我只能想到運行參數化查詢會帶來的一個好處:它會減少應用程序當前的SQL注入攻擊漏洞。從其他方面來看,你可能希望得到的最好結果是這個假設的即時解析器/解釋器不會破壞任何東西。

即使你不必自己寫這樣的東西(我敢打賭你也這樣做),這對於引入生產系統來說是一個非常重要的風險,特別是因爲這是一個權宜之計,當你重構時會被丟棄應用程序。 SQL注入攻擊的風險高到足以證明這一點?

0

你有沒有考慮在舊代碼上運行替代正則表達式?從當前查詢中提取值並將其替換爲參數,並在查詢行後附加Command.Parameters.AddWithValue(paramName,paramValue)調用可能是可能的,前提是當前內聯SQL都遵循相同的值(或者如果接近他們都是這樣做的,你可以在你最喜歡的編輯器中修復其餘部分)。