SQL Server- VBScript：在SQL Job中打開Excel文件失敗的VBScript？

Question

參考vbScript opens up excel but doesn't load macro/modules?

現在我試圖從SQL作業運行我的VBScript。儘管我成功地執行了Job，但它並沒有打開我的Excel文件（Checked Task Scheduler）。我去查看這項工作的歷史，發現

消息 作爲用戶執行：GSOPS4 \ SYSTEM。 Microsoft（R）Windows腳本宿主版本5.7版權所有（C）Microsoft Corporation。保留所有權利。C：\ WINDOWS \ system32 \ TestTOPTMay307.vbs（5，1）Microsoft Excel：Microsoft Excel無法訪問文件'\ gsops4 \ data_extracts \ TestTOPTMay307.xlsm'。有幾種可能的原因：文件名或路徑不存在。該文件正在被另一個程序使用。您嘗試保存的工作簿與當前打開的工作簿具有相同的名稱。處理退出代碼0.步驟成功。

我也跟着在這個線程Run a C# Console Application from SQL Server Agent (Job)?

但是我無法得到它的工作的建議。這件事在過去的48小時裏一直令我煩惱。任何線索是什麼導致它，以及如何成功地執行我的工作（從SQL運行我的VBScript文件）將不勝感激。謝謝大家！

有什麼想法？

Answer 1

另一種觀點

Excel是在控制檯上彈出對話框，然後掛，直到它們被用戶付諸行動很不錯。這是服務器上的一個壞東西，因爲它會凍結進程並泄漏正在運行的Excel實例。它還要求你在服務器上安裝excel。

通常情況下，通過OLEDB驅動程序讀取電子表格並在服務器端作業上覆制計算的代理程序，通過代理程序安排SSIS作業要好得多。宏究竟做了什麼？

我在Excel日誌中完成了一些ETL工作，並且（IMO）處理excel數據的最佳方法是避免不惜一切代價調用EXCEL.EXE。對於懸掛COM引用非常挑剔，所以你必須非常小心地處理所有創建的COM對象。在某些情況下，默認引用（Worksheet，Workbook，Range等）會在幕後創建不透明的引用，因爲類型庫不會公開任何工具。

.NET主互操作程序集爲此添加了額外的複雜性，因爲它們生成的自己的引用也必須明確地整理。在COM和.Net之間存在顯着的阻抗不匹配問題 - 就如何編寫幾本關於使COM和.Net組件良好結合在一起的書籍而言。

幸運的是，WSH並不涉及.Net，但COM COM遠程處理Excel COM服務器並不是我會推薦在DBMS中執行的操作。

兩個安全得多接近

1. 開啓在所述OLEDB驅動器工作簿 - 讀片材到一個臨時表，然後提取數據形式存在。這甚至不需要在服務器上安裝Excel，而且非常健壯。

2. 解開。xlsx壓縮文件並從中獲取工作表 - 這實際上比您想象的更好。 sheetxx.xml文件格式相當簡單，您可能需要的唯一其他內容是sharedStrings.xml。通常，如果您有SSIS，則不需要在SQL Server上執行此操作，但如果您在非Windows主機上使用（比如說）Oracle，則這是非常有用的技巧。

編輯： 爲了通過你需要有你運行它的計算機上安裝Excel OLE自動化使用Excel。通常，將Excel安裝在服務器上並不是一個好計劃，因爲它不是特別安全。這也是一個桌面工具，並且如果你沒有點擊你的I，並且通過你的COM參考創建和處理來交叉你的T，它就會泄漏COM引用並運行Excel實例。

SSIS有一個excel數據源。您可以通過在BIDS中創建SSIS項目並創建新的連接管理器來查看它。你的選擇之一是Excel。

但是，如果您需要查詢SharePoint列表，則最好不要使用Excel編程式地查詢它。 google-fu應該舉例說明如何做到這一點，例如here.。您可以通過獨立的.Net應用程序或通過SSIS包中的腳本任務來執行此操作（腳本任務是可以在SSIS包中構建的.Net自定義任務）。

如果你這樣做，你可能最好在SSIS之外開發它（如果沒有其他選項，請使用Visual C＃Express），然後將它移植到腳本任務中。如果你對Python很熟悉，IronPython或者Boo是交互式地使用.Net API進行工作的好工具。