開篇介紹
這個問題來自於 天善BI社區，看了一下比較有意思，因為我自己認為在 SSIS中處理各種類型文件的經驗還比較豐富(有一年的時間幾乎所有ETL都跟文件相關)，但是這個問題確實之前沒有特別考慮過。研究了一下，找到了解決的方法，趕緊記錄下來。
簡單描述一下這個問題，如果我們的 SOURCE 是直接從表里面查詢，然后輸出到文件的時候，查詢語句中列的順序就是輸出文件列的順序(逗號分隔的文件)。但是如果使用變量查詢語句，那么這個輸出順序和查詢列的順序就會不一致了！如果我們的文件格式已經提前定義好了，那么這個就很不好調整了。除非手動一列一列的在文件管理器中刪除所有列，然后重新建立，但這樣會非常耗費時間和精力，並且非常容易出錯。
解決過程
先看看問題，再來看比較簡單的解決方案。
測試數據源查詢語句和結果 -
如果是直接查詢的話，文件輸出列的順序沒有任何問題和影響，下面是我的查詢語句，和在 SQL Server 中的是一樣的。
OLE DB Source 里的順序與查詢語句一致。
向下關聯一個文件輸出並在它的連接管理器中可以看到這些順序都是一樣的，不需要做出任何調整。
最后的輸出結果也是一樣的，列的輸出順序都一致，沒有問題。
現在我們使用變量來保存這個查詢語句 -
在數據源中使用這個變量作為查詢語句來查詢 -
切換到 Columns 的時候發現非常詭異的地方出來了，整個列的輸出順序和查詢的順序不一樣了。並且更為詭異的問題是，同樣的兩個變量語句，我反復刪除試建了好幾次。第一個的順序和這個還不一樣，第二個正常，這是第三個順序。並且在最開始只測試幾個字段的時候，這個順序一直是正常的，現在看到的是我增加了好幾個列才看到的。關於為什么有這個變化，或者與寫沒寫 Top 10 我還真的沒有辦法重現剛才的第一個順序，總之問題出現了。
這樣輸出的時候，和文件管理器關聯之后的順序。以前的做法是先刪除所有的，然后重新一項一項添加回去，並且還要注意數據類型都要記下來。
但是這樣確實存在一個問題，如果我們的輸出列比較復雜，要不一個一個列的類型順序記載下來會非常花費時間和精力。可以在這里調整，但是總覺得是一個效率比較低的選擇。
輸出的結果果然如此，順序和期望的不一致！
解決的方法雖然也需要人工手動操作，但是比起在文件管理器中刪除新建要容易的多，回到數據源的列，先取消全部可用的列。
然后對照查詢語句列的順序，依次選中需要的列，比如第一個先勾選 BusinessEntityID，第二個再勾選 NationalIDNumber，后面根據需要按順序依次勾選。
按順序選擇完成之后，這樣所有的列又按照查詢順序輸出了。
需要重新建立新的文件鏈接管理器，這樣可以避免之前的緩存影響，再來看管理器中的列順序也是對應一致的，沒有問題了。
輸出結果也是一致的了！
寫到這里我也仍然懷疑，如果直接用表難道就一直沒有出現這個現象嗎，還是沒有碰到？ 這個確實記不清了，但是從這個問題反而使得另外的一個問題變得很清晰，也就是無論輸入源的查詢順序是怎么樣的，我們完全可以控制它的輸出順序。因為有的時候可能會碰到第三方直接給你一個視圖或者存儲過程，輸出的就是這樣的順序，但是下游文件格式已經固定了，那么就可以通過這種方式來完成自定義的順序向下輸出了。
更多 BI 文章請參看 BI 系列隨筆列表 (SSIS, SSRS, SSAS, MDX, SQL Server) 如果覺得這篇文章看了對您有幫助，請幫助推薦，以方便他人在 BIWORK 博客推薦欄中快速看到這些文章。