我有一个在 VS2012 中开发的包（使用 SQL 数据工具组件），它使用 VFPOLEDB 提供程序从 DBF 文件收集数据，并将其放入 SQL Server 2012 X64 服务器上的数据库中。包含该包的项目将 Run64BitRuntime 的 DebugOption 设置为 false。我已将此包导入到测试服务器和实时服务器的 SSIS 包存储中（相同的设置）。 VFPOLEDB 提供程序安装在两台计算机上，我可以在两台计算机的注册表中看到它适用于 32 位运行时。
该包在测试机器上运行良好，但在实际机器上失败。 SQL 的实时实例似乎无法识别已安装的 32 位 VFPOLEDB 提供程序。
SQL 实例的唯一区别是实时环境设置了集成服务目录，而测试则没有。查看服务器的日志，当实时启动时，它会运行 sp_ssis_startup，然后记录有关加载不安全程序集的消息。该 SP 未在测试环境中运行，因为没有目录。
我创建的作业将标志设置为使用 32 位运行时，但我忍不住觉得 SSIS 目录与我正在使用的 VFPOLEDB 存在问题，并且未加载它。
我对 SSIS 目录一无所知，所以有人能建议我可以前进的方向吗？
Update:
Here is my job step configuration. The 32bit runtime flag is set.
更新#2：
更新#3：
我刚刚检查过，测试环境和实际环境并不像我最初所说的那样。实时服务器没有 32 位版本的 dtexec.exe（尽管我认为这并不重要，因为TechNet https://msdn.microsoft.com/en-us/library/hh231187(v=sql.110).aspx#bit表示使用 SQL Server 代理运行的作业将始终使用 64 位版本。我想我使用了 x86 和 i64 ISO 来设置测试环境，但仅使用 64 位版本进行实时测试。我想，更改此设置需要从 Live Box 中卸载 Integration Services 共享组件，然后使用双 ISO 重新安装。
我想设置“使用 32 位运行时”选项只有在有 32 位版本可供使用时才有效？这或许可以解释一些事情。
默认情况下，一切都将以 64 位在服务器上运行。要更改此行为，您需要指出 32 位版本dtexec https://msdn.microsoft.com/en-us/library/hh231187.aspx应该使用。对于 2012 SSISDB，我们有两种简单的方法来调用我们的包：SQL 代理和catalog.start_execution方法。
对于单个服务包运行，您可以在 SSISDB 目录中找到该包并右键单击它们以Execute...
在弹出的对话框中，您需要转到“高级”选项卡并检查32-bit runtime盒子。这将在每次运行包时完成。
在幕后，向导生成的 SQL 看起来像
DECLARE @execution_id bigint
EXEC [SSISDB].[catalog].[create_execution]
@package_name = N'Package.dtsx'
, @execution_id = @execution_id OUTPUT
, @folder_name = N'POC'
, @project_name = N'SSISConfigMixAndMatch'
, @use32bitruntime = True
, @reference_id = NULL
SELECT
@execution_id
DECLARE @var0 smallint = 1
EXEC [SSISDB].[catalog].[set_execution_parameter_value]
@execution_id
, @object_type = 50
, @parameter_name = N'LOGGING_LEVEL'
, @parameter_value = @var0
EXEC [SSISDB].[catalog].[start_execution]
@execution_id
GO
如您所见，@use32bitruntime参数传递一个 True 值，表示它应该在 32 位空间中运行。
对于重复运行的包，我们通常使用调度工具。要在代理中获取程序包的 32 位设置，其单击路径基本相同，只是您首先需要单击“配置”选项卡并then单击“高级”选项卡进行选择32-bit runtime
作业步骤定义看起来像
EXEC msdb.dbo.sp_add_jobstep
@job_name = N'Do it'
, @step_name = N'Run in 32bit'
, @step_id = 1
, @cmdexec_success_code = 0
, @on_success_action = 1
, @on_fail_action = 2
, @retry_attempts = 0
, @retry_interval = 0
, @os_run_priority = 0
, @subsystem = N'SSIS'
, @command = N'/ISSERVER "\"\SSISDB\POC\SSISConfigMixAndMatch\Package.dtsx\"" /SERVER "\".\dev2014\"" /X86 /Par "\"$ServerOption::LOGGING_LEVEL(Int16)\"";1 /Par "\"$ServerOption::SYNCHRONIZED(Boolean)\"";True /CALLERINFO SQLAGENT /REPORTING E'
, @database_name = N'master'
, @flags = 0
您将看到在 @command 调用中，向导生成了/X86call 这是为 SQL Agent 保留的特殊参数（检查开头的 BOL 链接），以指示是否应使用 32 位版本或 64 位版本的 dtexec。命令行调用需要我们显式使用正确的 dtexec。默认情况下，64 位 dtexec 将在您的 PATH 环境中首先列出
它在一台服务器上运行，而不在另一台服务器上运行。
第 1 步 - 验证您已安装驱动程序。愚蠢，显而易见，但存在许多问题，人们错误地认为部署 SSIS 包/.ispac 也会部署所有引用的程序集。它不是 nuget，所以不，所有先决条件都需要安装，并且安装正确（看到人们尝试将程序集复制到 GAC 而不是使用该工具）
第 2 步 - 验证驱动程序安装在服务器之间是否匹配。再次，似乎很明显，但我经历过痛苦，通常是 VS_NEEDSNEWMETADATA，驱动程序版本 4.0.2.013 中的点差异产生了与 4.0.2.014 不同的结果
步骤 3 - 确保您定义的所有 DSN 均定义在正确的空间中。这种动物会因为多种原因咬人。我认为直到 Server 2012，您才只能通过在文件系统上找到 odbcad32.exe（与管理工具 -> 数据源 (ODBC) 相关的可执行文件）来获取 odbcad32.exe 的 32 位版本。更令人困惑的是，可执行文件的名称为 odbcad32.exe，无论它是在 System32 还是 SysWOW64 中，而这两个文件夹分别用于 64 位驱动程序和 32 位驱动程序。是的，未来的读者，这不是一个错字。 64位版本的应用程序位于System32中，32位版本位于SysWOW64中。这是一项旨在最大程度地减少影响的设计决策。
在测试和实时服务器上，运行C:\Windows\SysWOW64\odbcad32.exe找到您的 FoxPro 驱动程序和相关的 DSN，它们是否符合预期？
第 4 步 - 奇怪的权限检查。以“普通”帐户登录两台服务器，然后从命令行运行该包。重复此步骤，但使用代理执行它，无论您是否已定义代理。如果第一个有效但后者失败，通常表明存在权限问题。可能是 SQL Server 或代理帐户无法访问驱动程序安装到的任何文件夹。该帐户可能需要 InteractWithDesktop 权限或某些其他被拒绝或未明确授予的权限。