另一种观点
Excel 非常擅长在控制台上弹出对话框，然后挂起直到用户操作它们。这在服务器上是一件非常糟糕的事情，因为它会冻结进程并泄漏正在运行的 excel 实例。它还要求您在服务器本身上安装 excel。
通常，最好通过代理来安排 SSIS 作业，该代理通过 OLEDB 驱动程序读取电子表格，然后在服务器端作业上复制计算。宏到底是做什么的？
我在一天中从 Excel 源中完成了一些 ETL 工作，并且（IMO）处理 excel 数据的最佳方法是避免EXCEL.EXE不惜一切代价调用。悬空 COM 引用非常挑剔，因此您必须非常小心地处理所有创建的 COM 对象。在某些情况下，默认引用（工作表、工作簿、范围等）会在幕后创建不透明的引用，您实际上无法以编程方式整理这些引用，因为类型库没有公开任何这样做的工具。
.NET 主互操作程序集为此增加了额外的复杂性，因为它们生成了自己的引用，这些引用也必须明确整理。COM 和 .Net 之间存在显着的阻抗不匹配 - 以至于已经编写了几本关于使 COM 和 .Net 组件很好地协同工作的书籍。
幸运的是，WSH 不涉及 .Net，但 Excel COM 服务器上的 COM 远程处理不是我建议在 DBMS 中执行的操作。
两种更安全的方法
在 OLEDB 驱动程序中打开工作簿 - 将工作表读入临时表，然后在那里提取数据表格。这甚至不需要在服务器上安装 Excel，并且非常强大。
解开 .xlsx zip 文件并从中取出工作表 - 这实际上比您想象的要好。这些sheetxx.xml文件的格式相当简单，您可能需要的唯一其他内容是sharedStrings.xml. 通常，如果您有可用的 SSIS，则不需要对 SQL Server 执行此操作，但如果您在非 Windows 主机上使用（例如）Oracle，这将是一个非常有用的技巧。
编辑：
为了通过 OLE 自动化使用 Excel，您需要在运行它的机器上安装 Excel。一般来说，将 Excel 安装在服务器上并不是一个好计划，因为它不是特别安全。它也是一个桌面工具，如果您没有在您的 I 上打点并在您的 COM 引用创建和处置中交叉您的 T，则它有泄漏 COM 引用和运行 Excel 实例的趋势。
SSIS 有一个 excel 数据源。您可以通过在 BIDS 中创建 SSIS 项目并创建新的连接管理器来查看它。您的选择之一将是 Excel。
但是，如果您需要查询一个共享点列表，您最好不使用 Excel 以编程方式查询它。一点 google-fu 应该会出现一些如何做到这一点的例子，例如这里。. 您可以通过独立的 .Net 应用程序或通过 SSIS 包中的脚本任务执行此操作（脚本任务是可以在 SSIS 包中构建的 .Net 自定义任务）。
如果你这样做，你可能最好在 SSIS 之外开发它（如果你没有任何其他选择，请使用 Visual C# Express），然后将其移植到脚本任务。如果您熟悉 Python，IronPython 或 Boo 是很好的工具，可以交互地使用 .Net API 来让某些东西正常工作。