Are the posted questions getting worse?

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21757

    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

  • Lynn Pettis

    SSC Guru

    Points: 442360

    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.

     

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21757

    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

    MVDBA

  • Lynn Pettis

    SSC Guru

    Points: 442360

    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.

     

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21757

    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 🙂

     

    MVDBA

  • Grant Fritchey

    SSC Guru

    Points: 396715

    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.

    ----------------------------------------------------
    The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
    Theodore Roosevelt

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21757

    Grant Fritchey wrote:

    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

  • Chris Harshman

    SSC-Forever

    Points: 42157

    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:

    • 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.

    • 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.

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 720983

    Glad to see everyone is talking about SQL Server stuff. Hope you've had a good last month.

  • Michael L John

    One Orange Chip

    Points: 25950

    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/

  • Eirikur Eiriksson

    SSC Guru

    Points: 182511

    Steve Jones - SSC Editor wrote:

    Glad to see everyone is talking about SQL Server stuff. Hope you've had a good last month.

    the last 30.4375 days? 😉

    😎

  • frederico_fonseca

    SSChampion

    Points: 14754

    Chris Harshman wrote:

    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

    • Dynamically generated packages based on input data (c# code)
    • Master package that loads (c# script) another package to be able to change data flow sql variables on the fly (expressions not possible due to size limit)

    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.

  • Thom A

    SSC Guru

    Points: 98720

    Chris Harshman wrote:

    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.

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21757

    Michael L John wrote:

    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

  • below86

    SSChampion

    Points: 11352

    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 65,159 total)

You must be logged in to reply to this topic. Login to reply