From calendar alerts to information about our day, notifications allow us to never miss a thing. But what about in our work environment? Imagine it's closing time on a Friday and you execute a package or test knowing it will take hours, and leave for the weekend. What happens when it's Monday morning, you walk in expecting your results and see an error occurred moments after you left for the weekend? This situation can happen to anyone. Not only is it a huge waste of time, but it can be avoided.
'Are you sure it's not working? It was working just fine on my computer.' Sound familiar?
Errors are a part of production, but when going from development to production under a time crunch, you simply may not have the time or the workforce to go back and search through endless SQL statements and data flows. Maybe a SQL statement changed, or maybe your connection manager was altered, but what if it was something so small, it is almost impossible to find?
"What happened to my code? My expressions all worked last night!" Sound familiar?
For many developers and DBAs, this is all too common. Sometimes development can change overnight. A new team member implemented a change, a contractor came in while you were out of town; the possibilities for error are endless.
We understand that the world of data can seem daunting, especially when you're a n00b. For those of you that fall in that category, as a Product Engineer, I offer this advice: "All you need is dedication and the foresight to start small and slowly scale up. With this mindset, you'll achieve great things."
In case you missed yesterday's Intro to SSIS webinar, or would simply like a refresher of some of the main topics covered, I invite you to continue reading this blog post.
Time is money. As a developer, I want to code as quickly as possible, and although I know the importance of documentation, it can be a painful chore. "It takes a village to manage a database" ...is NOT how the saying goes, but chances are, there will be times when you're not the only one parsing through your data and environments. Without good documentation, you're going to bog down your fellow programmers and DBAs, and this inefficiency could really cost you at a crucial time in development.
Let's face it - data is the lifeblood of any company. And for SQL Developers and DBAs, knowing the relationships and origins of data can be the difference between meeting a deadline or not.
As a new Product Engineer at Pragmatic Works, I find that a common issue developers face is knowing what is going to break downstream upon making changes to their ecosystem, like a package or table name, for example. Additionally, a common question may be, "How did my data get into this column?"
Need help with this topic? Ask the author below.