February 26, 2020 at 9:37 am
I have to admit that I foolishly used the MSDB method (i'm no ssis expert, but i'm the best we have at our company) and hit a wall of pain with updating packages (hey we have to try and fail to improve), but the MSDB way can work (barely)
I think the big problem is that once you commit to once solution then it's quite hard to dig it out and turn it around
MVDBA
February 26, 2020 at 3:44 pm
I have to admit that I foolishly used the MSDB method (i'm no ssis expert, but i'm the best we have at our company) and hit a wall of pain with updating packages (hey we have to try and fail to improve), but the MSDB way can work (barely)
I think the big problem is that once you commit to once solution then it's quite hard to dig it out and turn it around
What? No self-esteem issues when failing?
Actually, glad to hear someone else saying that you learn from failures, as long as you don't repeat the same failures.
February 26, 2020 at 3:51 pm
MVDBA (Mike Vessey) wrote:I have to admit that I foolishly used the MSDB method (i'm no ssis expert, but i'm the best we have at our company) and hit a wall of pain with updating packages (hey we have to try and fail to improve), but the MSDB way can work (barely)
I think the big problem is that once you commit to once solution then it's quite hard to dig it out and turn it around
What? No self-esteem issues when failing?
Actually, glad to hear someone else saying that you learn from failures, as long as you don't repeat the same failures.
Lynn, we all know that you never fail. never have and never will 🙂 mine wasn't a failure it was a "rush to get things through before a deadline without proper planning or research and training" yep - failure to plan is planning to fail
MVDBA
February 26, 2020 at 3:59 pm
Lynn Pettis wrote:MVDBA (Mike Vessey) wrote:I have to admit that I foolishly used the MSDB method (i'm no ssis expert, but i'm the best we have at our company) and hit a wall of pain with updating packages (hey we have to try and fail to improve), but the MSDB way can work (barely)
I think the big problem is that once you commit to once solution then it's quite hard to dig it out and turn it around
What? No self-esteem issues when failing?
Actually, glad to hear someone else saying that you learn from failures, as long as you don't repeat the same failures.
Lynn, we all know that you never fail. never have and never will 🙂 mine wasn't a failure it was a "rush to get things through before a deadline without proper planning or research and training" yep - failure to plan is planning to fail
Trust me, I fail. The key is to learn from the failure and not repeat it, at least in the same way. It is fun finding different ways to make the same mistake (or error). I liked your comment about trying and failing to improve.
February 26, 2020 at 4:06 pm
MVDBA (Mike Vessey) wrote:Lynn Pettis wrote:MVDBA (Mike Vessey) wrote:I have to admit that I foolishly used the MSDB method (i'm no ssis expert, but i'm the best we have at our company) and hit a wall of pain with updating packages (hey we have to try and fail to improve), but the MSDB way can work (barely)
I think the big problem is that once you commit to once solution then it's quite hard to dig it out and turn it around
What? No self-esteem issues when failing?
Actually, glad to hear someone else saying that you learn from failures, as long as you don't repeat the same failures.
Lynn, we all know that you never fail. never have and never will 🙂 mine wasn't a failure it was a "rush to get things through before a deadline without proper planning or research and training" yep - failure to plan is planning to fail
Trust me, I fail. The key is to learn from the failure and not repeat it, at least in the same way. It is fun finding different ways to make the same mistake (or error). I liked your comment about trying and failing to improve.
Noooooo , the group of people who don't fail are you, Steve Jones, Grant, Kendra, Jeff.. do not shatter that illusion 🙂
MVDBA
February 26, 2020 at 4:16 pm
Lynn Pettis wrote:MVDBA (Mike Vessey) wrote:Lynn Pettis wrote:MVDBA (Mike Vessey) wrote:I have to admit that I foolishly used the MSDB method (i'm no ssis expert, but i'm the best we have at our company) and hit a wall of pain with updating packages (hey we have to try and fail to improve), but the MSDB way can work (barely)
I think the big problem is that once you commit to once solution then it's quite hard to dig it out and turn it around
What? No self-esteem issues when failing?
Actually, glad to hear someone else saying that you learn from failures, as long as you don't repeat the same failures.
Lynn, we all know that you never fail. never have and never will 🙂 mine wasn't a failure it was a "rush to get things through before a deadline without proper planning or research and training" yep - failure to plan is planning to fail
Trust me, I fail. The key is to learn from the failure and not repeat it, at least in the same way. It is fun finding different ways to make the same mistake (or error). I liked your comment about trying and failing to improve.
Noooooo , the group of people who don't fail are you, Steve Jones, Grant, Kendra, Jeff.. do not shatter that illusion 🙂
Oh yes. That's me. Never fail.
I'm sure the family would agree too.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 26, 2020 at 4:28 pm
MVDBA (Mike Vessey) wrote:Lynn Pettis wrote:MVDBA (Mike Vessey) wrote:Lynn Pettis wrote:MVDBA (Mike Vessey) wrote:I have to admit that I foolishly used the MSDB method (i'm no ssis expert, but i'm the best we have at our company) and hit a wall of pain with updating packages (hey we have to try and fail to improve), but the MSDB way can work (barely)
I think the big problem is that once you commit to once solution then it's quite hard to dig it out and turn it around
What? No self-esteem issues when failing?
Actually, glad to hear someone else saying that you learn from failures, as long as you don't repeat the same failures.
Lynn, we all know that you never fail. never have and never will 🙂 mine wasn't a failure it was a "rush to get things through before a deadline without proper planning or research and training" yep - failure to plan is planning to fail
Trust me, I fail. The key is to learn from the failure and not repeat it, at least in the same way. It is fun finding different ways to make the same mistake (or error). I liked your comment about trying and failing to improve.
Noooooo , the group of people who don't fail are you, Steve Jones, Grant, Kendra, Jeff.. do not shatter that illusion 🙂
Oh yes. That's me. Never fail.
I'm sure the family would agree too.
I nearly fell off my chair laughing because I wanted to say in a sarcastic way "so you could be wrong about about XE"? lol
ps - loving the articles you are putting out about XE over profiler.
MVDBA
February 26, 2020 at 5:30 pm
I really don't understand the amount of people that haven't changed the the Catalog, nor the resistance people give. The actual migration isn't actually that hard, provided you have good controls in place already (which I would hope many do!). We migrated as soon as we got 2012 and did it as part of the server upgrade, and it wasn't hard (and the resources were far fewer back then!).
I can tell you from my experience with it, I saw several issues which timewise prevented us from being able to migrate to the Catalog once we upgraded SQL Server. The biggest two were:
This may not seem like an issue to most people, but we often have multiple packages in a single project that would not be deployed together. Breaking those out to multiple projects would have been time intensive.
When running an SSIS pacakge, I found if you run it from the Catalog, it puts any information such as errors or other output into a different place within the Catalog instead of directly within the SQL Agent history. History just says to look at the "all executions" report. This would require someone to build out either new sets of permissions or new queries for computer operators and support teams to be able to monitor and troubleshoot scheduled packages.
February 26, 2020 at 5:41 pm
Glad to see everyone is talking about SQL Server stuff. Hope you've had a good last month.
February 26, 2020 at 6:49 pm
I don't know about the last month, the jury is still out, but last night was pretty good.
We were watching the Justice League movie. Myself, and my 10, 7, 5, and 3 year old grandsons. Of course, the 3 year old was off doing something else, but the 5 year old says "Are superheros real Pappy?". I said sure, maybe not Superman or Batman, but policemen, firemen, and paramedics are superheros. My 10 year old grandson jumps in and says "Pappy is a superhero!". Made my month!
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
February 26, 2020 at 7:41 pm
Thom A wrote:I really don't understand the amount of people that haven't changed the the Catalog, nor the resistance people give. The actual migration isn't actually that hard, provided you have good controls in place already (which I would hope many do!). We migrated as soon as we got 2012 and did it as part of the server upgrade, and it wasn't hard (and the resources were far fewer back then!).
I can tell you from my experience with it, I saw several issues which timewise prevented us from being able to migrate to the Catalog once we upgraded SQL Server. The biggest two were:
<li style="list-style-type: none;">
- Package Deployment vs Project Deployment
This may not seem like an issue to most people, but we often have multiple packages in a single project that would not be deployed together. Breaking those out to multiple projects would have been time intensive.
<li style="list-style-type: none;">
- SQL Agent Job History
When running an SSIS pacakge, I found if you run it from the Catalog, it puts any information such as errors or other output into a different place within the Catalog instead of directly within the SQL Agent history. History just says to look at the "all executions" report. This would require someone to build out either new sets of permissions or new queries for computer operators and support teams to be able to monitor and troubleshoot scheduled packages.
Add to the above
Catalog is good in many things - but its not for everything.
And for those that state "you can store passwords securely on the catalog" as if this was a "MAJOR" aspect of it - in SQL 2008 I was already storing encrypted passwords on config files and/or server tables, and more recently in one of my clients we retrieve the passwords from CyberArk on each execution of the packages.
February 27, 2020 at 8:57 am
I can tell you from my experience with it, I saw several issues which timewise prevented us from being able to migrate to the Catalog once we upgraded SQL Server. The biggest two were:
<li style="list-style-type: none;">
- Package Deployment vs Project Deployment
This may not seem like an issue to most people, but we often have multiple packages in a single project that would not be deployed together. Breaking those out to multiple projects would have been time intensive.
<li style="list-style-type: none;">
- SQL Agent Job History
When running an SSIS pacakge, I found if you run it from the Catalog, it puts any information such as errors or other output into a different place within the Catalog instead of directly within the SQL Agent history. History just says to look at the "all executions" report. This would require someone to build out either new sets of permissions or new queries for computer operators and support teams to be able to monitor and troubleshoot scheduled packages
You can now deploy packages separately again, which they added back in 2016, so it does support single package deployment again, which is good.
Personally, I don't find the logs being in a different place. You don't also execute a package via agent, so having them in 2 different places would be more problematic, in my view.
Glad to see you're back Steve, the article says you enjoyed time off. Hope you didn't come back to a too big of a pile of work. 🙂
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
February 27, 2020 at 9:04 am
I don't know about the last month, the jury is still out, but last night was pretty good.
We were watching the Justice League movie. Myself, and my 10, 7, 5, and 3 year old grandsons. Of course, the 3 year old was off doing something else, but the 5 year old says "Are superheros real Pappy?". I said sure, maybe not Superman or Batman, but policemen, firemen, and paramedics are superheros. My 10 year old grandson jumps in and says "Pappy is a superhero!". Made my month!
hey hold on you haven't told your grandchild about all the sql super heros? you only have to watch "the imitation game" which is basically the first decryption of Nazi code using a database...Turing was a genius out of his time. Thankfully "Pappy" can be that cool
MVDBA
February 28, 2020 at 5:22 pm
Another venting.. first thing though, I don't want to get into the whole argument on of using EOM vs BOM.
Where I work currently they use EOM. Which is fine with me and frankly what I'm used to and prefer. But what I don't understand about this place is they are setting this months EOM date as '02/28/2020'. I looked back and that's what they've done in past leap years, use 02/28/..... I've tried to tell them if we are going to use EOM then we need to use 02/29/2020 instead. I even tried to explain that by using EOM that certain date calculations are not going to work correctly when it goes to retrieve data for February 2020. Pointing out that if a report also brings in the prior months data the code would then be looking for 02/29 not 02/28. There is NOT a date table in place that everything is to use for these type of situations. Oh, well, I feel better that I vented.(I made sure to opened the windows 🙂
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
Viewing 15 posts - 64,516 through 64,530 (of 66,547 total)
You must be logged in to reply to this topic. Login to reply