SSIS 2015无法获取Excel连接管理器表信息及环境配置问询

Hey there, let's work through this SSIS Excel connection issue you're dealing with. I’ve run into similar conflicts between Office redistributables, SSIS, and SAP BO before, so here’s a structured approach to fix it:

• Fix 32/64-bit Runtime Mismatch
  Since you installed the 32-bit Access Redistributable 2016, SSIS might be trying to run in 64-bit mode which causes a driver conflict. Here’s how to adjust:

  • If you’re testing in SSDT: Go to Project Properties > Debugging > set Run64BitRuntime to False.
  • If deploying via SQL Server Agent: Open your job step, go to Execution Options, and check the box for Use 32-bit runtime.

• Re-register Office OLEDB Drivers
  Sometimes the redistributable doesn’t register correctly after uninstalling the 2010 version. Let’s manually register the required drivers:

  1. Open an elevated Command Prompt (right-click > Run as administrator).
  2. Navigate to your 32-bit Office 2016 directory: cd C:\Program Files (x86)\Microsoft Office\Office16
  3. Run these commands one by one:
     • regsvr32.exe msjetoledb40.dll
     • regsvr32.exe aceoledb.dll
       If you get a "module not found" error, double-check that the path matches your actual Office installation location—some setups might use a different folder.

• Clean Up Residual Conflicts from SAP BO & Old Office Components
  SAP BO BI 4.2 can leave behind conflicting registry entries or driver files that mess with SSIS. Try these steps:

  • Go to Programs and Features and uninstall any remaining 2010-era Office Access/ACE redistributables you might have missed.
  • Use Microsoft’s official Office uninstall tool to wipe out any leftover Office files or registry keys (important: back up your SAP BO settings first, as this tool might affect BO components too).
  • After cleaning, reinstall the 32-bit Access Redistributable 2016 and restart your server to apply changes.

• Check Permissions for Remote RDP Users
  Since some users access via remote desktop, make sure:

  • Their accounts have read/write permissions to the Excel file’s location (if it’s on a network share, verify both share and NTFS permissions).
  • They can access the OLEDB drivers used by SSIS. Have them test opening the Excel file directly and using Excel’s Data Connections feature to connect to it—if that fails, it’s a permission or driver access issue.

• Test with a Minimal SSIS Package
  Create a super simple package: just an Excel Connection Manager pointing to a test Excel file, plus a Data Flow Task that reads one sheet. Run this locally first, then have a remote user run it. If this works, the problem is likely in your original package (like invalid sheet names, protected Excel files, or data type mismatches) rather than the environment.

Quick note: That error message usually boils down to three things—driver registration problems, bitness mismatches, or permissions stopping SSIS from reading the Excel file’s schema.

内容的提问来源于stack exchange，提问作者d.tiles