有一張報表，是基於sql腳本查詢出的數據，一直是手動修改日期等關鍵字來每個月進行查詢，目前的需求是把它做成自動化，併在PowerBi上實時查詢。 我把其中的日期做了一些自動化獲取的處理，例如月初的獲取，例如工作日的獲取(上篇)等，在整個工作完成後，直接執行就能實時查詢出最新的數據，效果很好，準備放在 ...
有一張報表，是基於sql腳本查詢出的數據，一直是手動修改日期等關鍵字來每個月進行查詢，目前的需求是把它做成自動化，併在PowerBi上實時查詢。
我把其中的日期做了一些自動化獲取的處理，例如月初的獲取，例如工作日的獲取(上篇)等，在整個工作完成後，直接執行就能實時查詢出最新的數據，效果很好，準備放在PowerBi上使用Sql語句來DirectQuery，結果報了錯誤信息，如下：
在網上查找了下，有人這樣解釋
簡單來說，就是DirectQuery的查詢，是通過子查詢來實現的。
select * from ([你想執行的語句])
這樣的話，Declare肯定是會報錯的。
我做了同樣的實驗，在Excel中建立一個這樣的查詢，是完全沒有問題的，我註意到在Excel中，並沒有Import和DirectQuery的選項，我想了下，可能是在Excel中是通過手動點擊刷新，做了一遍重新導入的動作，這方面沒有深究，所以我打算通過Excel來獲得數據，然後在把它放在Onedrive上，接著再用PowerBi來獲取Onedrive上的Excel文件，PowerBi上支持把Excel解析成一個工作簿，也可以實現點擊實時刷新的效果，這是我昨天做的實驗，我甚至都要妥協，打算使用這種看起來只需要點擊的"簡單方式"來實現。
但是我仍然不甘心，在今天查詢到原因後，我打算麻煩一點，把所有定義的@關鍵字，全部替換成賦值的Sql腳本，因為基本上這樣的查詢，都是在腳本里定義一個欄位，去動態賦值而已，不像存儲過程，值需要手動輸入，所以這並不是什麼難事。
如果你定義的欄位不是通過系統函數，而是通過某張表來獲取某個欄位(例如上篇的工作日)，其實也只是把 @欄位 替換成 (select 欄位 from xxx ...) 括弧帶上，這樣放在外部的
select a,b,(select 欄位 from xxx),c from xxxxx... 也是完全沒有任何問題的。
這隻是我個人的一點小經驗而已，看起來很簡單，但是確是在不甘心妥協後找到的另外一種解決方式，這是很有意義的事情。想想看，通過Onedrive來做中轉和最初的只想實時查詢，做到了初心，這是讓人很有成就感的事情。
對於程式員來說，成就感很重要，不是嗎？:)
