Running SSIS 2008 on an instance of SQL2012

I am updating our solution and ETL databases to SQL Server 2012. I tested this update, but we have a discussion about launching the SSIS 2008 package with a job on an instance of SQL 2012. I understand that the job of the 2008 R2 instance is running:

Microsoft Post (R) SQL Server Execute Package Utility version 10.0.5500.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

Started: 2:10:11 AM DTExec: DTSER_SUCCESS (0) package executed ...

and the instance job 2012 updates the packages and does the following:

Message Completed as user: xxxx. Running SQL Server (R) Microsoft Batch Utility Version 11.0.2100.60 for 64-bit Copyright (C) Microsoft. All rights reserved. Started: 8:29:18 DTExec: Executing the package returns DTSER_SUCCESS (0). Started: 8:29:18 Ended: 8:59:46 a.m. Expired: 1816.76 seconds. package completed successfully. The stage has succeeded.

My question is this: are there crash reports for such a scenario and can it be assumed that there is backward compatibility?

+4
source share
3 answers

From this page , DTExec 2012 converts earlier version packages into memory in the 2012 format. It is possible that the conversion may fail, but it should be possible to check the packages, and if they succeed once (that is, convert successfully), then they should do it every time. Their behavior should look like a high degree, but I would not expect complete equivalence under any circumstances.

The most likely conversion failure scenario is that the package includes third-party components that are not available for SSIS 2012.

I would not assume that a package could be launched by a later version of DTExec without testing, but if it runs successfully once, there is a high probability that it will run successfully each time.

+3
source

Not 100% backward compatible. For instance. An edited SSIS 2008 package that extracts data from a flat file and does not specify row and column separators will work in 2008, but if you run this package on SSIS 2012, empty row and column separators will cause nut extraction, it will import millions of columns / rows (because it never finds the column / end of the line). A big problem for me now.

+1
source

There is one case where I found a problem with this that I would like to share: If you process SSAS cubes in SSIS 2008 packages, in rare cases the SSAS database connection provider will not work with the delayed version. See this link

0
source

Source: https://habr.com/ru/post/1501689/


All Articles