VB.NETで挑む「高信頼性データ同期」：SqlCommandBuilderの限界とトランザクションの極致
長年、VB.NETによるWindows Formsアプリケーションの最前線に立っていると、多くのエンジニアが「魔法の杖」を求めて彷徨うのを目にする。特に、DataGridView上の膨大なデータをSQL Serverへ流し込む際、`SqlCommandBuilder`を安易に使い、パフォーマンスの泥沼にはまる光景は、もはや様式美ですらある。
今日は、現場の人間が本当に知るべき、「泥臭くも確実な、バルクインサートとロールバックの最適解」を伝授する。
—
1. SqlCommandBuilderは「手軽な麻薬」である
多くの入門書は`SqlCommandBuilder`を推奨するが、大規模データや複雑な制約を持つテーブルにおいて、これはパフォーマンスの敵だ。実行のたびにスキーマ情報を取得し、クエリを自動生成するオーバーヘッドは、ネットワーク越しには無視できない遅延を生む。
シニアであれば、「`SqlBulkCopy`こそが正義」であることを理解せねばならない。
`SqlBulkCopy`は、SQL Serverの内部APIを直接叩くため、ログのオーバーヘッドを最小限に抑え、最速でレコードを挿入できる。これに、`SqlTransaction`を組み合わせることで、堅牢なデータ同期が可能になる。
—
2. 実装パターン：SqlBulkCopyによる高速挿入とトランザクション制御
以下は、メモリを極限まで節約しつつ、コネクションの切断を考慮したリトライロジックを含む、実務レベルのコード例だ。
Imports System.Data.SqlClient
Public Sub BulkInsertData(ByVal dt As DataTable, ByVal connectionString As String)
‘ メモリ最適化: IDisposableオブジェクトは必ずUsing句でスコープを限定する
Using conn As New SqlConnection(connectionString)
conn.Open()
‘ 明示的なトランザクションの開始
Using trans As SqlTransaction = conn.BeginTransaction()
Try
‘ SqlBulkCopyのインスタンス化（BatchSizeは1000〜5000が適当）
Using bulkCopy As New SqlBulkCopy(conn, SqlBulkCopyOptions.Default, trans)
bulkCopy.DestinationTableName = “TargetTable”
bulkCopy.BatchSize = 2000
bulkCopy.BulkCopyTimeout = 60 ‘ タイムアウトを明示
‘ 列マッピング（重要：ここを省略すると位置依存になり、DB設計変更で即死する）
bulkCopy.ColumnMappings.Add(“ID”, “ID”)
bulkCopy.ColumnMappings.Add(“Name”, “Name”)
bulkCopy.WriteToServer(dt)
End Using
trans.Commit()
Catch ex As SqlException
‘ ロールバック処理: ネットワーク切断や制約違反をキャッチ
trans.Rollback()
HandleNetworkError(ex)
Throw
End Try
End Using
End Using
End Sub
Private Sub HandleNetworkError(ex As SqlException)
‘ ここに指数バックオフ等のリトライロジックを実装する
‘ 伝説的なシステムは、エラーを単にログに吐くのではなく、”回復”を試みる
If ex.Number = -2 OrElse ex.Number = 10054 Then
‘ 接続再試行のロジックへ
End If
End Sub
—
3. レガシー環境を生き抜く「メモリとAPIの掌握」
Windows Formsアプリケーションにおいて、UIスレッドのフリーズは死を意味する。特に巨大なDataTableをメモリに展開してバルクインサートを行う場合、メモリの断片化（Fragment）が課題となる。
- DataTableの破棄: `dt.Dispose()`を呼び出し、ガベージコレクタ（GC）に頼らず明示的にメモリを解放せよ。
- Win32 APIの活用: `SendMessage`等を用いて、ウィンドウの再描画を一時的に停止（`WM_SETREDRAW`）させることで、グリッドの更新負荷を劇的に下げられる。これはVB6時代から続く、パフォーマンスチューニングの鉄則だ。
—
4. チーフアーキテクトからの助言
多くのエンジニアは「動けば良い」と考えがちだが、システムは「失敗した時の挙動」でその価値が決まる。
1. ネットワーク切断は必然と心得よ: トランザクション処理中に切断されることは、異常事態ではない。「起こりうる正常なフロー」として実装せよ。
2. ログは「状態」を残せ: エラー発生時のIDやタイムスタンプだけでなく、その時のコネクション状態やバッチサイズを記録することで、再現性のないバグを根絶できる。
3. 抽象化の罠: 何でもかんでも共通クラスを作ろうとするな。データアクセス層は、速度を犠牲にしてまで抽象化すべきではない。
VB.NETは、その堅牢な型システムゆえに、今なお大規模な業務システムを支える最強のツールだ。古い技術だと切り捨てる前に、まずはその足元のAPIをどこまで制御しきれているか、自問自答してみてほしい。
次回の記事では、`BackgroundWorker`を超えた、`Task Parallel Library (TPL)`を用いた非同期バルクインサートの真髄について語るとしよう。
現場からは以上だ。コードを書き続けろ。それがエンジニアの唯一の生存戦略だ。
