史丹利好熱

日前客戶IT通報有1個大型倉儲檔案(約1GB)FTP上傳2分鐘後就出現連線中斷的訊息:基礎連接已關閉: 接收時發生未預期的錯誤。

其他事證:

• 其他較小的檔案在同一台FTP Server傳送正常。
• 在命令提示字元下(cmd.exe)以FTP指令碼執行可以成功。

昨晚解決16進位字串轉Byte[]可以用在運算用途，今晚來解決與2進位字串(Binary，和BCD很像但不是)間的轉換。

考慮轉換過程方便，我們都先將來源字串轉換為Byte[]，再依照目的字串進位法需求轉出字串。(二進位)

• Hex string -> Byte[] -> Binary String
• Binary String -> Byte[] -> Hex String

碰到的幾種密碼演算法將明文的組成及密文的輸出使用16進位字串(Hex string)，但進行邏輯運算時則需要轉換為Byte[]，
為了便於使用，偷偷把轉換功能寫進Extensions，因為火星任務會用到。

• 16進位數字組成的字串轉換為Byte[]
• Byte[]轉換為16進位數字字串
• 取出字串右邊開始的指定數目字元

部分密碼演算法(Algorithm)有特殊的邏輯運算需求，筆記常用的Exclusive OR(XOR)⊕，順便複習OR及AND運算差異。

PIN Blocks、TripleDES..

為減少資料爭用避免擴大鎖定，我們常調整T-SQL或預存程序使用小量分批更新或寫入。
常用SqlBulkCopy來提升.NET大量資料寫入效能(真的很快)，那麼SqlBulkCopy會不會造成資料表鎖定(Tabe Lock)?
(1)會  (2)不會  (3)不一定 
 

繼ADO.NET Sqlcommand AddWithValue可能產生的效能問題，那麼Dapper有沒有類似的情形?

針對居家旅行 殺人滅口 必備良藥Dapper與參數化的實驗:

接獲客戶端IT通知，某個交易查詢約需6秒，調查資料存取物件是簡單的ADO.NET Sqlcommand，簡單的語法加上參數化查詢AddWithValue，

疑，AddWithValue

ADO.NET呼叫帶入資料表值參數的預存程序失敗，錯誤訊息:

資料表值參數不可以使用資料庫名稱，只有結構描述名稱和類型名稱是有效的。
Database name is not allowed with a table-valued parameter, only schema name and type name are valid

在SQL Server資料庫端SELECT * FROM  .NET端 SqlBulkCopy大量複製進來的(#TEMP)Temporary Table

• (方案1)Table variable (user type)
• (方案2)Temporary table

Mainframe主機環境中當批次執行太久，想釋放CPU資源給其他批次執行時，我們會調整較低等級的Priority或者將這支JOB Cancel，最近搜尋了在開放系統.NET環境的作法。

筆記一下需求及解決方案:

由外部Process發出

• 暫停批次
• 被暫停的批次繼續執行
• 取消批次

AssemblyInfo (*AssemblyVersion) Metadata

無法載入檔案或組件，找到的組件資訊清單定義與組件參考不符。

X86 vs X64