Excel 连接管理器通过 SSIS VS19 连接失败

Question

New to the SSIS world and I got it working before on Excel Version 2016 & Version 2007-2010 [after ages of troubleshooting] but then it just stopped working [endless testing on various solutions I've read, seems to be a reoccurring issue] and now it continues to not work.... any assistance would be appreciated.

Here's the situation: Importing Excel to the SSIS environment via VS19. when I try to view the Table in the Excel Source Editor, it comes up with the following error message:

Could not retrieve the table information for the connection manager 'Excel Connection Manager'. Failed to connect to the source using the connection manager 'Excel Connection Manager'.

• Using Visual Studio Community 2019 - 16.6.30128.74
• Using a 32-bit Excel from Microsoft Suite for Microsoft 365 on Windows 10 - 16.0.11929.20776
• In Visual Studio Installer, I have activated the "Data storage and processing" tile with the "SQL Server Data Tools" ticked

• I am running the package in 32-bit mode

  Project properties >> Debugging >> Run64BitRuntime = False

• I have installed both AcccessDatabaseEngine 32bit and 64bit for 2010 & 2016 on my computer -- x64 2010 redistributable - 14.0.7015.1000 -- x32 2010 redistributable - 14.0.7015.1000 -- x64 2016 redistributable - 16.0.4519.1000 -- x32 2016 redistributable - 16.0.4519.1000

• Have even done the Passive/Quiet model installation steps

  1. Open the Command Prompt by typing cmd in the Windows search box under the Start menu and selecting cmd.exe
  2. Type the file path and file name of the [relevant] install file, followed by a space and /passive or /quiet [if passive didn't work] .
  3. Open the Registry Editor by typing regedit in the Windows search box under the Start menu and selecting regedit.exe
  4. Deleted the mso.dll registry value in the following registry key:

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Common\FilesPaths"

[above for 2010] and [below for 2016]

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Common\FilesPaths"

• I've tried uninstalling and reinstalling the SSDT
• I've tried using all available excel version options [2007-2010, 2013, 2016] in the Excel Source Editor to no avail

• I've even tried the DelayValidation method someone suggested [still didn't work]

  Project Task >> Properties >> DelayValidation = True

• Even checked my connection string on my Excel Connection Manager

  Excel Connection Manager Connection >> Properties >> ConnectionString >> Provider=Microsoft.ACE.OLEDB.12.0

• Ran a repair on both my VS19 and my Office

• Made sure that all my excel files were closed

Current workaround: I've had to save all my excel files to a.xls versions and change the config to 97-2003 in order for my SSIS to register the tables from the workbook. What am I doing wrong? Am I missing something? It was working before and now it's C#$% itself.

Can someone please suggest another solution of why I can't use my excel 2010, 2013 or 2016 version to import my Excel Source to my SSIS environment in VS19 please. Thank you.

Answer 1

So, I basically had to start from scratch. Wipe my laptop and reinstall everything. SSMS, VS all the add-ons, everything. Now it works perfectly, so I think it's either the sequence that I've downloaded things or something that was already in my laptop was stopping the applications from working properly. Gosh that was a nightmare. But my problem is now fixed.

Answer 2

From what I've seen, the problem develops almost immediately after installing Office 365. Verify you are, in fact, using 32-bit Office 365. All indications that I have encountered, Office 365 is 64-bit and the installation process REMOVES the 32-bit prior versions of Office products. And that's where the problems start.

Installing the AccessDatabaseEngine is a junkyard patch to put a 32-bit dll back into your system for Visual Studio to use when you run in 32-bit mode. It's imperfect and may not give you all the required 32-bit dlls that the newer versions of Visual Studio require, which is why results can be flaky.

The core of the problem is actually Visual Studio. The development environment EXE, even in VS 2019, is still 32-bit. Thus, when you hit F5 to run your app, the Dev Env EXE forces all dlls to use 32-bit versions. And Office 365 has forcibly removed the Excel 32-bit dlls during installation, which is why so many people do the junkyard patch (above).

If there were some way to force VS to use a 64-bit dev env EXE, then all these problems go away. But until then, you are stuck with setting all flags to use 64-bit (so you can read the most recent Excel files), deploying your code to a server that has the 64-bit dlls, then using hope-and-pray methods. You will be working mostly blind, but you should be able to get some results.