Maybe you might want to separate out your query into multiple queries to get a response sooner and not get the timeout. 

The timeout is set as a way to make sure things arent left hanging when querying a DB that may be unreachable or too slow. 

Alternatively, you might want to create a script/other procedure in which you take the information you need from the DB you need it and store it to a temporary holding DB that you can then use a normal "Query Data" activity to grab such information. You would be able to set a wait for a metadata field or action to occur before doing the "Query Data" activity and you can have the wait take longer than 10 minutes without fear of an error or warning.

Hi Miled,

Before you extend the timeout, have you done every thing you can to optimise the database and query? Sorry if that sounds a bit obvious but it has to be asked. I'm suspicious of any query that takes so long and wonder if the query time will just continue to grow, unless the database and/query have been tuned.

Does the stored procedure create a dataset that is mostly static? Would generating the results once a day suffice or does the information need to be more up to date than that? If the dataset can be generated once a day, for example, then perhaps Kenneth's alternative approach might suffice.

I suspect there are better approaches that extending the time out and it would be very helpful to know about the scenario.

-Ben

Thank you all for your  responses, 

we have already optimized the Stored procedure as much as we can. This stored procedure is retrieving a huge number of records from different data sources.

Is there a way to change the SQL data source's default timeout? I am receiving the error after 30 seconds of execution, and I have checked the SQL remote query time out, it is 600 seconds.