傑士伯的IT學習之路

方式一: 採用 LINQ 的 Contains 方法
方式二: 自行撰寫 WHERE IN 的 SQL 敘述
方式三: 採用 Stored Procedure, 自行傳入 Table-Valued Parameter
方式四: 採用 Stored Procedure, 利用 EntityFrameworkExtras.EF6, 傳入 Table-Valued Parameter

以下茲以傳入多個產品類別, 去取出對應的產品資料為例, 進行說明.
本篇文章的編排比較類似個人的筆記, 說明會放在程式碼裡, 或圖片即能理解, 就不多作說明.

相關程式, 可由此下載

2019年12月14日星期六

[COBOL] ACUCOBOL COMP DATA TYPE 解析

0. 前言

最近的專案, 有將 ACUCOBOL 資料檔轉入至 DB 的需求.
最簡單的方式, 當然是針對每個 COBOL 資料檔, 撰寫 COBOL 程式, 各自轉為轉為固定長度的文字檔, 例如: 有 10 個資料檔, 就寫 10 支轉檔程式; 再採以下任一方案:
方案一: 撰寫 Java 或 C# 程式, 排程後, 定期轉至 DB.
方案二: 建立 SSIS Package (source: flat file, destination: ole db), 排程後, 定期轉至 DB.

但事與願違, 客戶想說, 是否可以採通用目的轉檔程式就好, 把整筆 COBOL 資料, 寫到 Binary Sequential 檔案; 由 Java 或 C# 讀取, 轉至 DB. 這樣就不需額外定義固定長度的文字檔 (即 COBOL 的 FD 檔), COBOL 的轉檔程式也變得很單純.

這是沒錯啦, COBOL 變單純了, 但 Java 或 C# 就會變複雜了.
然而並不是每一個 Java 或 C# 的程式設計師, 都了解 COBOL.
COBOL 主要有 2 種資料型態:

X: 字元型態.
9: 數值型態.
但因為古早的時候, 主機記憶體及磁碟空間有限, 所以有了 COMP 的壓縮方式, 以節省空間; 不只 COMP, 還有一些 SIGN LEADING, SIGN TRAILING ... 等的修飾詞.

要由 Java 或 C# 把 COMP 的內容解開, 必須理解各種 COMP 的資料壓縮方式.

筆者的第 1 份工作, 就是用 COBOL 寫醫療系統, 對 COMP 還有一些印象; 所以, 就上網查了一些資料, 並寫了一支 COBOL 程式, 作了一下驗證.
本文主要就是針對 COBOL 數值 COMP 型態的儲存格式, 進行整理.

2019年8月14日星期三

[C#] 如何進行變數或物件的相同(ReferenceEquals) 或相等(Equals) 的比較: 由 int / string 的原始程式碼談起

0. 前言

在撰寫單元測試時, 常會需要作 expected 與 actual 的比較, 常用的是 Assert.AreSame() 或 Assert.AreEqual().

關於 AreSame() 的部份, 很容易理解, 就是同一個記憶體區塊. 例如:

void Main()
{
    var a = new Customer();
    var b = a;
    Console.WriteLine(Object.ReferenceEquals(a, b));
}
public class Customer
{
    public int Id { get; set; }
    public string Name {get; set; }
}

則變數 b 與變數 a 是相同的, 因為指向同一個 Customer 物件.
即 Object.ReferenceEqual(a,b) 會回傳 True.

關於 AreEqual() 的部份, 則會因對於相等的定義不同, 而有不同的結果. 例如:
有 2 個 Box (具有長/寬/高/顏色 4 個屬性), 我們可以定義它的相等是:

長/寬/高都各自相等即可
長/寬/高都各自相等之外, 顏色也要相等

因此, 會有不同各自認定的規則, 來確定是否相等.

在 "相等" 的實作方面, 網路上查到了 91 哥的 2 篇文章 (參考文件2 / 參考文件3). 有提到可採用一些的方式作轉換後, 進行比較, 例如:

覆寫 Object 類別的 Equals() / GetHashCode()
轉換成匿名型別, 再作比較
轉換成 Expected Objects, 再作比較

本篇文章的編排比較類似個人的筆記, 說明會放在程式碼裡, 或圖片即能理解, 就不多作說明, 主要內容為:

由 int / string 等內建的資料型別, 如何達到 "相等" 的比較開始談起
再延伸至自訂類別, 如何達到 "相等" 的比較
Dictionay<T> 是如何作到去掉重複
LINQ 的 OrderBy() 是如何作到的

2019年1月6日星期日

[SQL Server] How to view the page content with DBCC PAGE (2) : 進階篇

0. 前言

筆者經由前一篇 [SQL Server] How to view the page content with DBCC PAGE (1) : 基礎篇的撰稿過程, 對 DBCC IND 及 DBCC PAGE 的使用, 大致上有了一些了解; 但都是經由其輸出的結果來探查 page 的內容, 並未看到其內部是如何儲存的; 故欲透過撰寫本文的過程, 對其內部結構能夠有所理解.

本文主要以參考文件06, 參考文件12, 參考文件13, 參考文件14 這4篇為主要的參考對象; 故文章內容, 可能會與前4篇有些重疊或重複, 感謝這 4 篇文章的作者.
測試資料的部份, 係採自前一篇, 故建議由前一篇開始閱讀.

本文將區分為以下幾個部份進行探討:
1. Data Page 的結構
2. Data Page 各筆資料的結構
3. UPDATE 的實地觀察 (定長欄位)
4. UPDATE 的實地觀察 (可變長度欄位)

筆者已盡力查詢相關資料, 但有些文章, 受限於個人的能力, 無法全盤瞭解;
故本文僅以個人所能理解的部份作說明.

2018年9月4日星期二

[SQL Server] How to view the page content with DBCC PAGE (1) : 基礎篇

0. 前言

將近2年前, 筆者曾針對 non-clustered index 的 page 結構, 在 facebook 的 Super SQL Server 社團中詢問, 如本連結, 並非常感謝 Levis Yang, 劉修仁 ... 等前輩的指點, 而有了一些瞭解.

一直以來, 很想對 SQL Server index page 及 data page 的結構及內容, 都有很大的好奇心; 直到最近, 才有機會作一些整理.

對此主題有興趣, 但對 SQL Server 的 index 仍不是很熟悉的朋友, 建議先閱讀參考文件01 及參考文件02.

筆者已盡力查詢相關資料, 但有些文章, 受限於個人的能力, 無法全盤瞭解; 故本文僅以個人所能理解的部份作說明.

訂閱：文章 (Atom)

2020年12月28日 星期一

0. 前言

2020年12月25日 星期五

需求

2020年1月5日 星期日

0. 前言

2019年12月14日 星期六

0. 前言

2019年8月14日 星期三

0. 前言

2019年1月6日 星期日

0. 前言

2018年9月4日 星期二

0. 前言

2020年12月28日星期一

2020年12月25日星期五

2020年1月5日星期日

2019年12月14日星期六

2019年8月14日星期三

2019年1月6日星期日

2018年9月4日星期二