February 21, 2020 at 2:56 pm
MVDBA (Mike Vessey) wrote:are we allowed to post links to "let me google that for you" ? lmgtfy.com 🙂 🙂
I've posted a lot of questions in the last few days relating to 2019 upgrades, but I take quite a while to put everything I think is relevant in the question.. and if I find a solution then I put it in a reply so that other people can see it (and then disagree with me 🙂 )
I've seen Jeff use those links many of times. And unlike certain sites, SSC won't post you submitting your post if it does contain a link to it. 😉
Can you? Yes.
Should you? Personally, I'd say no.
Have I done it? Yes, I did do it a couple of times. I regret it now and won't do it anymore. Even the answer I gave above was to an article I found, not to Google or LTGFY.
Will I call you on it? Nah.
"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 21, 2020 at 3:05 pm
I suppose lmgtfy.com could be construed as "sarcastic"? but it is tempting sometimes.
Better to be a nice DBA and not discourage people trying to learn.
BAD DBA for even thinking about using it!!!!
MVDBA
February 21, 2020 at 3:54 pm
One thing I've noticed since Google went on its personalization kick a few years back is that my results often don't look like your results.
412-977-3526 call/text
February 24, 2020 at 8:50 am
Robert Sterbal wrote:One thing I've noticed since Google went on its personalization kick a few years back is that my results often don't look like your results.
I was wondering why mine were full of beer, guitars and curries! 🙂
I was wondering why mine was whisky, underwear models and motorbikes lol
MVDBA
February 25, 2020 at 7:20 pm
So, not sure if you're still taking requests for changes to the site, but if you are, I find the "automated bump to increase visibility of your post" posts, to be annoying. Even when it's my own post getting bumped...
February 26, 2020 at 12:17 am
OK, bit of a vent here, feel free to ignore me...
WHY can you not use DTUTIL to import a password-protected SSIS package? Honestly, why? Today I had to migrate somewhere around 80 packages to our new environment, export was easy, found a handy query that generates the DTUTIL to export, found out the ones set to have the server roles protect the package needed to be dumped a little differently (and couldn't find a way to sort out the sheep from the goats in a query, so all the packages got passworded,) so a quick modification and voila, a bunch of DTSX files to copy.
Then I tried to DTUTIL to import them.
And well, that led to this grouch.
And before anyone asks, the customer whose packages I was working on, when I've pushed them towards migrating their packages to the SSIS Catalog?
"We've got to much other work to do," "It's a lot of work we don't have time for," etc, etc. Thankfully, my team lead is on-board with, once we finish our cloud migration, requiring them to get the ball rolling. Even going so far as to say my idea of "when we migrate to SQL 2019, the DBA will NOT be putting in the work to migrate your SSIS packages. Either you do it yourselves, or you get them in the SSIS Catalog."
Which, even I know, will probably still end up with me migrating them (again,) but it's worth a try...
February 26, 2020 at 4:25 am
OK, bit of a vent here, feel free to ignore me...
WHY can you not use DTUTIL to import a password-protected SSIS package? Honestly, why? Today I had to migrate somewhere around 80 packages to our new environment, export was easy, found a handy query that generates the DTUTIL to export, found out the ones set to have the server roles protect the package needed to be dumped a little differently (and couldn't find a way to sort out the sheep from the goats in a query, so all the packages got passworded,) so a quick modification and voila, a bunch of DTSX files to copy.
Then I tried to DTUTIL to import them.
And well, that led to this grouch.
And before anyone asks, the customer whose packages I was working on, when I've pushed them towards migrating their packages to the SSIS Catalog?
"We've got to much other work to do," "It's a lot of work we don't have time for," etc, etc. Thankfully, my team lead is on-board with, once we finish our cloud migration, requiring them to get the ball rolling. Even going so far as to say my idea of "when we migrate to SQL 2019, the DBA will NOT be putting in the work to migrate your SSIS packages. Either you do it yourselves, or you get them in the SSIS Catalog."
Which, even I know, will probably still end up with me migrating them (again,) but it's worth a try...
Heh... if you're going to grouch about, I'm going to grouch with you... 😀 You're not the only one that has gone through this. I've seen many a soul suffer through SSIS migrations, deployments, whatever. A good friend of mine went through this same junk with close to 200 packages they had to migrate. Even the consultant they hired to do it quit. You've touched upon one of the many significant reasons why I do whatever I can to avoid SSIS at all costs and why I help them tear down SSIS and do it all with a little SQL prestidigitation in stored procedures. What others went through during 2014 SP1 put the lid on SSIS for me.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2020 at 9:22 am
And before anyone asks, the customer whose packages I was working on, when I've pushed them towards migrating their packages to the SSIS Catalog?
"We've got to much other work to do," "It's a lot of work we don't have time for," etc, etc. Thankfully, my team lead is on-board with, once we finish our cloud migration, requiring them to get the ball rolling. Even going so far as to say my idea of "when we migrate to SQL 2019, the DBA will NOT be putting in the work to migrate your SSIS packages. Either you do it yourselves, or you get them in the SSIS Catalog."..
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 do often wonder it's a cause of that a lot of people think that SSIS is "bad" (*cough* Jeff *cough*) and so don't want to rock the boat. Problem is, rocking that boat actually causes it's the rock less later on.
Maybe Microsoft will Deprecate the msdb and file system deployment methods; then everyone will be forced to use SSIS Catalog. Heh 😉
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
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
Viewing 15 posts - 64,501 through 64,515 (of 66,815 total)
You must be logged in to reply to this topic. Login to reply