bcp產出的資料中，若欄位為空會寫入NUL，故利用powershell將NUL置換掉。
但因檔案是要給linux系統使用，故原本bcp產出的資料是以LF斷行，但經過powershell處理後，會自動將斷行符號換成CRLF。
所以改寫ps檔如下，最後再還原LF斷行.....一波好幾折...
((Get-Content c:\temp\test.txt) -join "`n") + "`n"| ForEach-Object { $_ -replace "`0", "" } | Set-Content -NoNewline c:\temp\test.new
主機事件檢視器在dimension或cube process時，一直不斷出現安全性下的稽核失敗。造成3分鐘內20筆稽核失敗被視為資安警認通報，訊息摘要如下：
帳戶無法登入
登入失敗的帳戶
安全性識別碼：NULL SID
帳號名稱：admin
帳號網域：TESTBI
失敗原因：未將這台機器上要求的登入類型授與使用者。
The user has not been granted the requested logon type (aka logon right) at this machine
登入類型：8
呼叫者理程序名稱： "C:\Program Files\Microsoft SQL Server\MSAS15.SQL2019\OLAP\bin\msmdsrv.exe"
依照登入類型=8，查到NetworkCleartext 使用者從網路登入此電腦。 使用者的密碼已傳遞至其未顯示表單的驗證套件。 內建的驗證會先封裝所有雜湊認證，再傳送給整個網路。 認證不會以純文字或純文字 (稱為 cleartext) 。
但並無任何排程有使用到明碼作認證?而且OLAP查詢或處理也都很正常?
找了好久，最後在OLAP 資料庫的資料來源中看到安全性設定，原本使用ImpersonateAccount 以系統帳號做認證，不知為何，在此台主機如此設定就會有eventid 4625 稽核失敗的紀錄，但另外一台主機同樣的設定則沒有問題。
將模擬資訊改為繼承後，重新處理dimension或cube，事件檢視器就再無稽核失敗問題了。
