別の見方
Excel は、コンソールにダイアログを表示して、ユーザーが操作するまでハングアップするのが得意です。これは、プロセスがフリーズし、実行中の Excel インスタンスがリークするため、サーバーでは非常に悪いことです。また、サーバー自体に Excel をインストールする必要があります。
一般に、OLEDB ドライバーを介してスプレッドシートを読み取るエージェントを介して SSIS ジョブをスケジュールし、サーバー側のジョブで計算を複製する方がはるかに優れています。マクロは正確に何をしますか？
私は 1 日に Excel ソースからいくつかの ETL ジョブを実行しましたが、(IMO) Excel からデータを処理する最善の方法は、なんとしてでも呼び出す必要を避けることEXCEL.EXEです。ぶら下がっている COM 参照は非常に扱いにくいため、作成されたすべての COM オブジェクトを破棄する際には十分に注意する必要があります。場合によっては、既定の参照 (Worksheet、Workbook、Range など) によって、バックグラウンドで不透明な参照が作成されます。タイプ ライブラリはそのための機能を公開していないため、プログラムで実際に整理することはできません。
.NET プライマリ相互運用機能アセンブリは、明示的に整理する必要がある独自の参照を生成するため、これにさらに複雑さを加えます。COM と .Net の間にはかなりのインピーダンスの不一致があります。COM と .Net コンポーネントをうまく連携させる方法について書かれた本がいくつかあるほどです。
幸いなことに、WSH には .Net が含まれていませんが、Excel COM サーバーでの COM リモート処理は、DBMS 内から実行することをお勧めしません。
より安全な 2 つのアプローチ
OLEDB ドライバーでワークブックを開きます。シートをステージング テーブルに読み込み、そこでデータ フォームを抽出します。これは、サーバーに Excel をインストールする必要さえなく、非常に堅牢です。
.xlsx zip ファイルを解き、そこからワークシートを取り出します。これは実際には、思ったよりもうまく機能します。ファイルはsheetxx.xmlかなり単純な形式であり、他に必要になる可能性が高いのはsharedStrings.xml. 通常、SSIS を使用できる場合は SQL Server でこれを行う必要はありませんが、Windows 以外のホストで (たとえば) Oracle を使用している場合は非常に便利な方法です。
編集:
OLE オートメーションを介して Excel を使用するには、Excel を実行しているマシンに Excel をインストールする必要があります。一般に、サーバーに Excel をインストールすることは特に安全ではないため、あまりお勧めできません。これはデスクトップ ツールでもあり、I にドットを付けたり、T を COM 参照の作成および破棄と交差させたりしないと、COM 参照と実行中の Excel インスタンスがリークする傾向があります。
SSIS には Excel データ ソースがあります。BIDS で SSIS プロジェクトを作成し、新しい接続マネージャーを作成することで確認できます。オプションの 1 つに Excel があります。
ただし、SharePoint リストを照会する必要がある場合は、Excel をまったく使用せずにプログラムで照会することをお勧めします。ちょっとした google-fu は、これを行う方法のいくつかの例を表示する必要があります。. これは、スタンドアロンの .Net アプリまたは SSIS パッケージのスクリプト タスクを介して行うことができます (スクリプト タスクは、SSIS パッケージ内で構築できる .Net カスタム タスクです)。
これを行う場合は、SSIS の外部で開発し (他に選択肢がない場合は Visual C# Express を使用)、スクリプト タスクに移植する方がよいでしょう。Python に精通している場合、IronPython または Boo は、.Net API をインタラクティブに操作して何かを機能させるための優れたツールです。