Let’s say that you have a source database and a destination database. Let’s take this one step further and say that you have multiple instances of these source and destination databases deployed in your environment. Let’s make things a little more complicated by saying that there can be (and probably are) different versions of these databases deployed, and that you track the current version in a database table. To make matters worse, it’s possible that a corresponding source/destination pair might be updated at different times, so their versions might not always match.
This sounds like a pain in the butt, but also sounds like a pretty common scenario too. So how do you ensure that the SSIS package that you’re developing will only move data from source to destination if their versions match? With SSIS variables and Expressions, the solutions is very simple. Here’s what’s needed:
- Two connection managers, one for the source database and one for the destination database.
- Two package variables, one to store the version number from the source database and one to store the version number from the destination database.
- Two Execute SQL tasks, one to retrieve the version number from the source database and one to retrieve the version number from the destination database and store them in the variables.
- A sequence container around the two Execute SQL tasks. This is technically optional, but it makes it easier to build the package logic if you set things up this way.
- One precedence constraint configured with a Success constraint and an SSIS Expression instead of just using a Success/Failure/Completion constraint.
- Optionally, a second precedence constraint set up with a completion constraint logically opposite Expression, so you can have a second path of execution for when the versions do not match.
- The rest of your package logic. This is up to you, I’m afraid.
When you’re done, you’ll have something that looks a lot like this: