The Execution method successfully failed



  • I'm sure there's some pedantic dickweed justification for this error but anyone who's had to deal with SSIS will probably understand why I'm not giving it the benefit of the doubt.

    The WTF

    The method executed successfully but an error occurred which made the method fail. Makes sense... surprised I haven't heard of any politicians using similar logic yet ("My bill succeeded! It succeeded in failing!!").

    Bonus WTF is that SQL server raises a warning to tell me there was an error (obviously superior to just raising an error in the first place). I also like the suggestion to just raise the max number of errors to fix the problem.



  •  Remember, if you fail to plan to succeed, you plan to succeed to fail.  Or something like that.



  • Just today I was importing some Excel spreadsheets into SQL Server. It's never easy. They seriously had to make that tool as complicated as they could.



  • Ow man, the conversion crap I get to deal with when importing Excels into SQL Server using SSIS... Automatically casting shit to numbers when I need the prefix '0', interpreting '23-02-2012' as february 23 (Correct, we're in the Netherlands), but '3-4-2012' as march 4, looking only at the first N rows and deciding a varchar(20) is sufficient, having a varchar(50) at row N+1 will break it... The list goes on. Usually, I just save the Excel sheet to CSV format and import it through Flat File Connector. Much more configurable.



  • @da Doctah said:

     Remember, if you fail to plan to succeed, you plan to succeed to fail.  Or something like that.

     

    What happens if you succeed to plan to fail?

     



  • @bullrider718 said:

    I'm sure there's some pedantic dickweed justification for this error but anyone who's had to deal with SSIS will probably understand why I'm not giving it the benefit of the doubt.

    If only you'd chosen to use SS[b]D[/b]S instead, you wouldn't have this problem...



  • Usually, I just save the Excel sheet to CSV format and import it through Flat File Connector. Much more configurable.

    Yeah, I cleaned up the data in Excel, exported to tab delimited and then to SQL Server. It's the only way in hell it would work.


  • Winner of the 2016 Presidential Election

    @steenbergh said:

    interpreting '23-02-2012' as february 23 (Correct, we're in the Netherlands), but '3-4-2012' as march 4

    TRWTF is using anything except yyyy-MM-dd for dates anywhere but the presentation layer.



  • @joe.edwards said:

    @steenbergh said:
    interpreting '23-02-2012' as february 23 (Correct, we're in the Netherlands), but '3-4-2012' as march 4

    TRWTF is using anything except yyyy-MM-dd for dates anywhere but the presentation layer.

     if you're not in the presentation layer, why do your dares have a text representation at all? 1337er than you!!!!



  • @bullrider718 said:

    I'm sure there's some pedantic dickweed justification for this error

    ...Which, if I'm remembering correctly, is that when you set up an SSIS import, you can tell it what amounts to "this is the maximum number of rows you are allowed to have trouble importing before it's actually considered a problem, but in the meantime, keep importing all the rows you can."


  • Winner of the 2016 Presidential Election

    @blakeyrat said:

     if you're not in the presentation layer, why do your dares have a text representation at all? 1337er than you!!!!

    The persistence layer? There are many reasons to serialize data into a string. Network transmission, for example, or storage in an XML file.



  • @joe.edwards said:

    Network transmission, for example, or storage in an XML file.
     

    Surely the format here doesn't matter until you get to the storage part - when it's transformed into a presentable format for the XML - rather than transform it early then squirt it around in that format.



  • @kilroo said:

    @bullrider718 said:

    I'm sure there's some pedantic dickweed justification for this error

    ...Which, if I'm remembering correctly, is that when you set up an SSIS import, you can tell it what amounts to "this is the maximum number of rows you are allowed to have trouble importing before it's actually considered a problem, but in the meantime, keep importing all the rows you can."

    It wasn't an import... it was an attempt to copy a database. I think the point still stands that it failed but said it was successful.

    I've also used the ETL tools before briefly and it seemed to enjoy completely ignoring any row redirection rules configured for failed rows.


  • Winner of the 2016 Presidential Election

    @Cassidy said:

    Surely the format here doesn't matter until you get to the storage part - when it's transformed into a presentable format for the XML - rather than transform it early then squirt it around in that format.

    OK but the context here is importing an Excel file, so it is already in the storage part. So why is Excel storing the dates in a nonstandard form? And don't say because the user entered them that way, Excel knows the data type of each field and is capable of normalization.



  • FYI when I end a post with three exclamation marks you can assume it's a joke and not reply.



  • @dhromed said:

    @da Doctah said:

     Remember, if you fail to plan to succeed, you plan to succeed to fail.  Or something like that.

     

    What happens if you succeed to plan to fail?

     

    Phase 3: Profit!

     



  • @joe.edwards said:

    OK but the context here is importing an Excel file, so it is already in the storage part.
     

    Aha, thought you were talking about in general rather than this particular situation. Ignore me.



  • @dhromed said:

    @da Doctah said:

     Remember, if you fail to plan to succeed, you plan to succeed to fail.  Or something like that.

     

    What happens if you succeed to plan to fail?

     


    Then you'll fail, provided you succeed.



  • @blakeyrat said:

    FYI when I end a post with three exclamation marks you can assume it's a joke and not reply.
     

    FYI when he starts a post with three exclamation marks you can assume he's an excited Mexican and deport him!!!


  • Winner of the 2016 Presidential Election

    @Lorne Kates said:

    FYI when he startsbegins a post with three exclamation marks you can assume he's an excited Mexican and deport him!!!



  • @Lorne Kates said:

    FYI when he starts a post with three exclamation marks you can assume he's an excited Mexican and deport him!!!

    Only if they're inverted.



  • @blakeyrat said:

    FYI when I end a post with three exclamation marks you can assume it's a joke and not reply.

    But you ended with 4, so that is not applicable here.


  • Winner of the 2016 Presidential Election

    @locallunatic said:

    But you ended with 4, so that is not applicable here.

    Technically, he also ended with 3.



  • @blakeyrat said:

    @Lorne Kates said:
    FYI when he starts a post with three exclamation marks you can assume he's an excited Mexican and deport him!!!

    Only if they're inverted.

     

    If they aren't, he's a Mexican in training.  You can often scare him into a plea bargin where he'll turn in the high-ranking members of his Mexican cell.



  • @bullrider718 said:

    @kilroo said:
    @bullrider718 said:

    I'm sure there's some pedantic dickweed justification for this error

    ...Which, if I'm remembering correctly, is that when you set up an SSIS import, you can tell it what amounts to "this is the maximum number of rows you are allowed to have trouble importing before it's actually considered a problem, but in the meantime, keep importing all the rows you can."

    It wasn't an import... it was an attempt to copy a database. I think the point still stands that it failed but said it was successful.

    I've also used the ETL tools before briefly and it seemed to enjoy completely ignoring any row redirection rules configured for failed rows.

    A "Copy Database" in this way is simply a combination of exporting data from souce A and importing into destination B.

    Personally, I have really good luck with SSIS.  It has a lot of flexibility and runs very stable... definately not the old DTS which was horrible to work with.  After SQL Server 2005 SP1 (the first SP for SSIS) it has worked well, with the little bugs that all of these types of tools have ... any I have seen, that is, which is not saying very much.



  • @bullrider718 said:

    I'm sure there's some pedantic dickweed justification for this error but anyone who's had to deal with SSIS will probably understand why I'm not giving it the benefit of the doubt.

    The method executed successfully but an error occurred which made the method fail. Makes sense... surprised I haven't heard of any politicians using similar logic yet ("My bill succeeded! It succeeded in failing!!").

    Bonus WTF is that SQL server raises a warning to tell me there was an error (obviously superior to just raising an error in the first place). I also like the suggestion to just raise the max number of errors to fix the problem.

    Wait, this is in Windows' application event log?  Then it makes sense.  The package failed, but SSIS did not fail.  You should not see errors in the application log unless their was a serious failure.  An SSIS package erroring out does not rise to that level.  The SSIS runtime crashing would.

    And there are times where you want to raise the MaximumErrorCount -- not many, but their are times where a failure under certain cicumstances is normal, but you do not want to stop all of the package flow just because the error was raised.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.