我正在将我们的ETL解决方案和数据库升级到SQL Server 2012.我已经测试了这个升级，但我们讨论了如何在SQL 2012实例上运行带有Job的SSIS 2008包。我了解2008 R2实例作业运行：
消息Microsoft（R）SQL Server执行包实用程序版本 适用于64位的10.0.5500.0版权所有（C）Microsoft Corp 1984-2005。保留所有权利。
开始时间：2：10：11 AM DTExec：程序包执行返回 DTSER_SUCCESS（0）......
并且2012实例作业执行包和运行的就地升级：
消息以用户身份执行：xxxx。 Microsoft（R）SQL Server执行 包实用程序版本11.0.2100.60 for 64位版权所有（C） 微软公司。版权所有。开始时间：上午8:29:18 DTExec：包执行返回DTSER_SUCCESS（0）。入门： 上午8:29:18完成时间：上午8:59:46经过：1816.76秒。该 包执行成功。这一步成功了。
我的问题是：是否有任何关于此类情况失败的报告，是否可以安全地假设存在向后兼容性？
答案 0 :(得分：3)
从this page开始，DTExec 2012将早期版本的内存包转换为2012格式。可以想象转换可能会失败，但是，应该可以测试包，如果它们成功运行一次（即转换成功），那么它们每次都应该这样做。他们的行为应该与高度相似，但我不希望在所有情况下完全等同。
转换失败的最可能方案是该软件包是否包含不适用于SSIS 2012的第三方组件。
我不会假设一个软件包可以在没有测试的情况下由更高版本的DTExec运行，但如果它成功运行一次，则每次运行成功的可能性很高。
答案 1 :(得分：1)
不是100％向后兼容。例如。 SSIS 2008编辑的软件包，从平面文件中提取数据，但未指定行和文件。列分隔符将在2008年工作，但如果您在SSIS 2012服务器上运行该程序包，则空行和＆amp;列分隔符将导致提取变得坚果，它将导入数以万计的列/行（因为它永远不会找到列/行结尾）。对我来说最重要的问题是，
答案 2 :(得分：0)
有一个案例我发现了一个我想分享的问题： 如果您在SSIS 2008包中处理SSAS多维数据集，在极少数情况下，SSAS数据库连接提供程序将无法使用过时版本。请参阅this链接