The Matrix is everywhere. It is all around us. Even now, in this very room. You can see it when you look out your window or when you turn on your television. You can feel it when you go to work… when you go to church… when you pay your taxes. It is the world that has been pulled over your eyes to blind you from the truth.
That you are a slave, Neo. Like everyone else you were born into bondage. Into a prison that you cannot taste or see or touch. A prison for your mind.
This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland and I show you how deep the rabbit-hole goes.
SFMC Support can certainly tell you exactly what the error was, and now you can (sometimes) see some error details in the Activity tab of Automation Studio.
Here are a few things that I’ve found are common things that cause Query Activities to fail.
Primary key violation
If your query results in duplicate rows not allowed by the primary key, then you’ll need to change your primary key or de-duplicate the rows that result from your query. Here’s my go-to method for deduplication. The innermost query sorts by insertDate, groups by email address and assigns a ranking to each row. The outermost query selects only the top result per email address.
Inserting a null value into a non-nullable field
If you have fields in your target Data Extension that are non-nullable, you need to ensure none of the columns in your query return a null value. You can utilize the isnull() SQL function to handle that situation:
Inserting a value too long for the field (truncation)
If any of your source data extension columns are larger than the target, then you can adjust the length of the target column or use the left() SQL function to trim the value:
Probably the most frustrating error is the the 30 minute timeout. If your query won’t run in that amount of time, then it’ll error out. There are a bunch of different ways to address query timeouts. Here are some tips:
First and foremost, you need to reduce the number of row you’re querying. This can be altering your date range or adding additional criteria to target rows more specifically.
Leverage the primary keys for speed. While we don’t have any insight in to the indexes that SFMC behind the scenes, it’s a good bet the primary keys are indexes. So the more utilize their values in the where-clause, the better.
Don’t join multiple System Data Views in your query. It’s a pain, but it’s a good practice to have a separate query for each activity (sends, opens, clicks, etc.). Last resort is to make your own copies of the System Data Views with primary keys and refresh them on an interval. The data extension versions will perform better.
Make sure your where-clause conditionals are sargable to reduce the number of type-conversions and to optimize the selection:
If it’s still timing out, leave a comment below with some details. I have some other tricks to share.