locked
Partion processing query returns zero records throws errors logged in the event log RRS feed

  • Question

  • Hi,

    We are running ETL which runs the below pseudo code.

    try

    {

    ProcessPartition();

    }

    catch(Exception e)

    {

    LogError(e);

    If(e == "No Data Found")

    {

        taskResult = Success

    }

    else

    {

        // Some other type of exception

        taskResult = Failure;

    }

    }

    but the issue is that whenever we runs it and partition processing returns zero results it throws some error in the event log. Event though we are trying to catch it thru ETL it is still logging error in event Log. Is there any way we can avoid this situation.We do not want to fail other tasks because of the partition task is failed.

    The error it throws in Trace is XYZ' column does
    not exist in the rowset

    Regards

    Rajaniesh

     
    Thursday, June 29, 2017 6:03 PM

Answers

  • Thank YOU for a quick answer. Really appreciate it. So does it mean that even though we are catching this error but due to the fatal nature of the error it will still log this error into the event log and unless we resolve the column mapping we can not avoid this error?.

     

    Yes, I believe so, this is not a transient error like a timeout that might go away if you retry the process. This a fatal flaw in the design and the model needs to be manually corrected and re-deployed to fix this.

    But catching the error in your code and the SSAS service writing out the event log are two different things. When you catch the error in your code you are just affecting how your code treats the error. From the SSAS perspective the error has still occurred and been passed back to the calling application, it is unaware of how the calling code has chosen to deal with it. And having an error written to the event log should not have any impact on your ETL code, it's going to be how you set the taskResult that determines that.


    http://darren.gosbell.com - please mark correct answers

    Thursday, July 6, 2017 7:07 AM

All replies

  • Hi Rajaniesh Kaushikk,

    What's the task you are using in Integration Services?

    Generally, in terms of SSIS, we could ignore the error of task by suppressing propagation in the Event Handlers. I assume you have a script task in Event Handlers on Error tab. Then you could change the value of system variable propagate to False to prevent error propagation. For more information, you could refer to: SSIS Logging and Event Propagation

    If I misunderstand your requirement, please share exact requirement and provide an example if possible. That will be more helpful.

    Regards,

    Pirlo Zhang


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, June 30, 2017 8:49 AM
  • Hi Pirlo,

    I agree that the errors like  "'xyz' column does not exist in the rowset" can be ignored because these error indicates that when the partition is getting processed, the underlying query returned 0 records. So in this case when query returns no records, SSAS actually throws an exception. I do not know why? This exception eventually fails our entire ETL flow. But since, we  do not want the entire flow to fail the ETL so we moved the partition processing code into C# component and starting catching this exception and logging it, This way our ETL does not fail.

    The outcome of it is that we still see the job completing successfully, but the Event Log will still have these SSAS errors logged and it keep filling the event Log with this error.

    Is there any way to avoid this situation ?

    Is there any way to know beforehand that partition will fail because of column does not exists so not to process it and avoid SSAS throwing this error. Something like existential check?

    Regards
    Rajaniesh

    Friday, June 30, 2017 1:19 PM
  • Is there any way to avoid this situation ?

    This error means that you have a column in your tabular table, but your partition query is not returning the source column for this.

    The easy way to fix this error is to either remove the column from your tabular table if you are not using it, or include this source for this column in the query. 


    http://darren.gosbell.com - please mark correct answers

    Sunday, July 2, 2017 2:42 AM
  • Hi,

    My fundamental question is not answered?

    Regards

    Rajaniesh

    Wednesday, July 5, 2017 1:34 PM
  • My fundamental question is not answered?

    It's not clear what you consider to be your fundamental question. I would have thought that it was correcting the fatal configuration error in your column mappings was the fundamental issue here. Your partition is never going process successfully while it is in this state.

    It's also not clear what behaviour you are observing. Are you saying that the code goes into the catch block, but you think that it shouldn't? Or that it doesn't get caught be the catch block and you think it should? Or is it going into the catch block and also writing to the Windows Event log? (this is a fatal configuration error, the partition will never process while it's in this state, I don't believe you can stop this level of error from being written to the event log)

     

    http://darren.gosbell.com - please mark correct answers

    Wednesday, July 5, 2017 8:39 PM
  • Thank YOU for a quick answer. Really appreciate it. So does it mean that even though we are catching this error but due to the fatal nature of the error it will still log this error into the event log and unless we resolve the column mapping we can not avoid this error?.

     
    Thursday, July 6, 2017 3:22 AM
  • Thank YOU for a quick answer. Really appreciate it. So does it mean that even though we are catching this error but due to the fatal nature of the error it will still log this error into the event log and unless we resolve the column mapping we can not avoid this error?.

     

    Yes, I believe so, this is not a transient error like a timeout that might go away if you retry the process. This a fatal flaw in the design and the model needs to be manually corrected and re-deployed to fix this.

    But catching the error in your code and the SSAS service writing out the event log are two different things. When you catch the error in your code you are just affecting how your code treats the error. From the SSAS perspective the error has still occurred and been passed back to the calling application, it is unaware of how the calling code has chosen to deal with it. And having an error written to the event log should not have any impact on your ETL code, it's going to be how you set the taskResult that determines that.


    http://darren.gosbell.com - please mark correct answers

    Thursday, July 6, 2017 7:07 AM