I'm currently getting the following error when editing and deleting scheduled reports in SSRS: "Only members of sysadmin role are allowed to update or delete jobs owned by a different login."
I've tried changing the owner of the jobs to the Service account used by SSRS, I've added that users as a sysadmin and I've checked the user and password for the limited account for the Reporting Services itself. Nothing is making a difference.
The reporting services log just shows:
w3wp!library!a!06/03/2009-01:23:42:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.InternalCatalogException: An internal error occurred on the report server. See the error log for more details., ;
Info: Microsoft.ReportingServices.Diagnostics.Utilities.InternalCatalogException: An internal error occurred on the report server. See the error log for more details. ---> System.Data.SqlClient.SqlException: Only members of sysadmin role are allowed to update or delete jobs owned by a different login.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at Microsoft.ReportingServices.Library.InstrumentedSqlCommand.ExecuteNonQuery()
at Microsoft.ReportingServices.Library.SqlAgentScheduler.DeleteTask(Guid id)
at Microsoft.ReportingServices.Library.SchedulingDBInterface.UpdateTaskProperties(Task task, Boolean updateSqlAgentSchedule)
at Microsoft.ReportingServices.Library.TimedSubscriptionHandler.ValidateSubscriptionData(Subscription subscription, String subscriptionData, UserContext userContext)
at Microsoft.ReportingServices.Library.SubscriptionManager.ValidateSubscriptionData(Subscription subscription, String eventType, String subscriptionData)
at Microsoft.ReportingServices.Library.SubscriptionManager.SetSubscriptionProperties(Guid id, String eventType, String matchData, ExtensionSettings extensionSettings, String description, ParameterValueOrFieldReference[] parameters, DataRetrievalPlan dataSettings)
at Microsoft.ReportingServices.Library.SetSubscriptionPropertiesAction.PerformActionNow()
at Microsoft.ReportingServices.Library.RSSoapAction`1.Execute()
--- End of inner exception stack trace ---
I found the problem. The SSRS application pool in IIS for the Reports Manager is running as the Network Service user, which was being used as the connection context even though the application using the service is loging in as the limited user.
Solutions:
Change the application pool to a user that has SysAdmin rights or ownership of the jobs in the DB
Or add the Network Service user as a SQL user and SysAdmin
I have same issue with SSRS 2005.
Not all reports are like this but have struck the odd subscription that cannot be updated/removed.
IIS runs on one server as builtin network and the tables are on a separate clustered server. I cannot grant the IIS builtin account rights to the tables on the remote database server.
I have had some luck with finding the itemid of the report in the catalog, matching the report_oid in the subscriptions table and deleting the row with the affected subscription itemid.
Sounds awful but after this I can recreate the subscription and all is good in the world.
Related
I am working on jobs currently and when I want to deploy my project I am receiving the following error. I tried to check the DTSPath but I wasn't able to find it under the following path "go to regedit->HKEY_LOCAL_MACHINE->SOFTWARES and under Microsoft Sql Server in SSIS"
The path for 'ISServerExec.exe' cannot be found. The operation will
now exit. A .NET Framework error occurred during execution of
user-defined routine or aggregate "deploy_project_internal":
System.Data.SqlClient.SqlException: The path for 'ISServerExec.exe'
cannot be found. The operation will now exit.
System.Data.SqlClient.SqlException: at
System.Data.SqlClient.SqlConnection.OnError(SqlException exception,
Boolean breakConnection, Action`1 wrapCloseInAction) at
System.Data.SqlClient.SqlInternalConnectionSmi.EventSink.DispatchMessages(Boolean
ignoreNonFatalMessages) at
System.Data.SqlClient.SqlCommand.RunExecuteNonQuerySmi(Boolean
sendToPipe) at
System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource
1 completion, String methodName, Boolean sendToPipe, Int32 timeout,
Boolean& usedCache, Boolean asyncWrite, Boolean inRetry) at
System.Data.SqlClient.SqlCommand.ExecuteToPipe(SmiContext pipeContext)
at Microsoft.SqlServer.Server.SqlPipe.ExecuteAndSend(SqlCommand
command) at
Microsoft.SqlServer.IntegrationServices.Server.ServerConnectionControl.RaiseError(SysMessageId
messageId, SysMessageSeverity severity, Object[] args) at
Microsoft.SqlServer.IntegrationServices.Server.ServerApi.DeployProjectInternal(SqlInt64
deployId, SqlInt64 versionId, SqlInt64 projectId, SqlString
projectName) . (Microsoft SQL Server, Error: 27108)
This solved my problem immediately:
http://thesqlgirl.com/2017/10/25/ssis-error-the-path-for-isserverexec-exe-cannot-be-found/
When I re-ran the SQL Installer and selected the instance I was having trouble with, I found that SSIS (Integration Services) wasn't installed, just like the article above suggested. Somehow, when I had removed a secondary instance of SQL that was running on same server, it affected other instances.
Not shocking for a Microsoft product.
In SQL server every time i got Filegroup is full, Execution timeout. How can i release some space in SQL database.
System.Data.SqlClient.SqlException: Timeout expired. The timeout
period elapsed prior to completion of the operation or the server is
not responding. at
System.Data.SqlClient.SqlConnection.OnError(SqlException exception,
Boolean breakConnection) at
System.Data.SqlClient.SqlInternalConnection.OnError(SqlException
exception, Boolean breakConnection) at
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject
stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior
runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream,
BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject
stateObj)
You can shrink the SQL Server Database Size.
Step 1: Right-click on the database name >> Tasks >> Shrink >> Database.
Step 2: Then Click OK.
for more details you can read the following blog https://stackoverflow.com/a/18292136/1805776
I'm expecting this behavior because of this MSDN article about the AttachDbFileName property
The first time you connect to a database by using this option in the
connection string, the SQL Server Express or LocalDB instance attaches
the database, and it stays attached. When you want to connect to the
same database in the future you could use Initial Catalog without
AttachDbFileName if you prefer.
I have a connection string that is used by Entity Framework:
<add name="DatabaseContext" providerName="System.Data.SqlClient" connectionString="Server=(localdb)\MSSQLLocalDB;Database=DatabaseName;Integrated Security=True;AttachDbFileName=|DatabaseName|\DatabaseName.mdf" />
This works fine after I open the database in SQL Management Studio feeding it the AttachDbFileName value with the absolute path as an additional prameter.
But if I don't attached it with SQL Management Studio first then I'm getting the following error when trying to run EF migrations on the database:
System.Data.SqlClient.SqlException (0x80131904): Cannot create file 'C:\Users\user\Desktop\folder\DatabaseName.mdf' because it already exists. Change the file path or the file name, and retry the operation.
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.<NonQuery>b__0(DbCommand t, DbCommandInterceptionContext`1 c)
at System.Data.Entity.Infrastructure.Interception.InternalDispatcher`1.Dispatch[TTarget,TInterceptionContext,TResult](TTarget target, Func`3 operation, TInterceptionContext interceptionContext, Action`3 executing, Action`3 executed)
at System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.NonQuery(DbCommand command, DbCommandInterceptionContext interceptionContext)
at System.Data.Entity.SqlServer.SqlProviderServices.<>c__DisplayClass1a.<CreateDatabaseFromScript>b__19(DbConnection conn)
at System.Data.Entity.SqlServer.SqlProviderServices.<>c__DisplayClass33.<UsingConnection>b__32()
at System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.<>c__DisplayClass1.<Execute>b__0()
at System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.Execute[TResult](Func`1 operation)
at System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.Execute(Action operation)
at System.Data.Entity.SqlServer.SqlProviderServices.UsingConnection(DbConnection sqlConnection, Action`1 act)
at System.Data.Entity.SqlServer.SqlProviderServices.UsingMasterConnection(DbConnection sqlConnection, Action`1 act)
at System.Data.Entity.SqlServer.SqlProviderServices.CreateDatabaseFromScript(Nullable`1 commandTimeout, DbConnection sqlConnection, String createDatabaseScript)
at System.Data.Entity.SqlServer.SqlProviderServices.DbCreateDatabase(DbConnection connection, Nullable`1 commandTimeout, StoreItemCollection storeItemCollection)
at System.Data.Entity.Core.Common.DbProviderServices.CreateDatabase(DbConnection connection, Nullable`1 commandTimeout, StoreItemCollection storeItemCollection)
at System.Data.Entity.Core.Objects.ObjectContext.CreateDatabase()
at System.Data.Entity.Migrations.Utilities.DatabaseCreator.Create(DbConnection connection)
at System.Data.Entity.Migrations.DbMigrator.EnsureDatabaseExists(Action mustSucceedToKeepDatabase)
at System.Data.Entity.Migrations.DbMigrator.Update(String targetMigration)
at System.Data.Entity.Migrations.Infrastructure.MigratorBase.Update()
This looks as if it doesn't attach the database automatically for some reason and then tries to create it as if the file didn't exist.
Is there an additional connection string option or LocalDB configuration that can fix this so that the database is attached automatically on the first conneciton?
Reviewing the Web.Config may help to understand what happened here. The LocalDB is a database that is meant to serve as a file. If you have an actual database you could change the connection string. Either way, check the version of your localdb (example 2019 would be version 15 of sql server and version 13 of the localdb). If the one in the connection string (web.config) points to a different location, it is a task for editing the connection string.
https://www.connectionstrings.com/store-connection-string-in-webconfig/
The answer is trivial: the .mdf and .ldf files were created in a newer version of SQL server so the older version was not attaching them as if they didn't exist.
Before reading please note that I've googled this and read a ton of articles on SO and elsewhere, no suggestions have worked as of yet.
I'm randomly getting a timeout error that occurs when logging into my MVC 3 application. It happens well over half of the time - all other times the application logs on just fine. When it doesn't work, it tries for about 10 seconds then errors.
The error:
Exception: "An error occurred while executing the command definition. See the inner exception for details."
Inner Exception: {"Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.\r\nTimeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding."}
This happens inside my repository class that directly interacts with entity framework.
It seems to happen when logging in and simply pulling a quick check from the database, such as:
return entities.Users.SingleOrDefault(user => user.UserName == userName);
return (entities.Users.SingleOrDefault(u => u.UserId == user.UserId || u.UserName == user.UserName) != null);
Things I've tried:
SQL Server validation
Integrated Security (I even gave every possible account full database access)
Running outside of IIS
Setting Connect Timeout extremely high (Connect Timeout=50000) in the connection string. (I do not have Default Command Timeout set here)
Setting the CommandTimeout to 0, 5000, 100000, whatever, on my entity connection: entities.CommandTieout = 100000;
Setting the CommandTimeout inside every using statement where I use an instance of the repository.
Flipping SingleOrDefault to FirstOrDefault etc.
Enabling/Disabling Lazy Loading (Why not?)
If it helps:
I am using a custom role and membership provider.
I'm just making calls from my controller inside a using statement (AccountRepository bleh = new AccountRepository()) and the AccountRepository implements IDisposable etc.
The entity model is in a separate project.
I'm running the site in IIS. It's setup with the 4.0 integrated app pool.
All accounts have full database access.
When the error occurs, it doesn't take no where near as long as I have set in the web config (50000 I think) or for the commandtimeout in the repository.
It's not doing much on the login, just validating user, getting user role then loading up some small amount data, but the error always occurs when getting the user data on login.
When I try it outside of debugging it repeats the error four or five times (with custom errors off).
Here is the full exception from the event log:
Exception information:
Exception type: SqlException
Exception message: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
You could examine the problem from the database server by setting up a SQL Server Profiler.
You can find lots of info about SQL Profiler by just googling around. Here's a site with a video that might help you get started.
Edit: While this did indeed help me it was not the solution. The problem still exists for anyone reading in the future.
Just to let everyone know - I believe that I have found the issue. Through the SQL Profiler, I saw that the account being used to access SQL was in fact the local system account. I then realized that in an attempt to fix an issue prior, I had changed the ASP.NET v4.0 app pool to use the local system account. I went and changed the Identity back to 'ApplicationPoolIdentity', added the IIS APPPOOL\ASP.NET v4.0 user to the database and so far everything has been working great. #DOK - Thank you much for the information on SQL Profiler, it helped tremendously! Thanks everyone else also!
I have a multithreaded Windows Service I've developed with VS 2010 (.NET 4.0) which can have anywhere from a few to a few dozen threads, each retrieving data from a slow server over the Internet and then using a local database to record this data (so the process is Internet-bound, not LAN or CPU bound).
With some regularity, I am getting a flood/flurry/burst of the following error from several threads simultaneously:
System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
The call stack for this error is typically:
at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
I'm not specifying a Connection Timeout in the connection string, and there are other applications and processes working in this database. Has anyone come across this kind of behavior and if so what was done to prevent it?
The most commonly-called method in my data access layer looks like this, and all my other DAL methods follow the same approach:
using (SqlConnection con = new SqlConnection(GetConnectionString()))
using (SqlCommand cmd = new SqlCommand("AddGdsMonitorLogEntry", con))
{
cmd.CommandType = CommandType.StoredProcedure;
/* setting cmd.Parameters [snipped] */
// We have been getting some timeouts writing to the log; wait a little longer than the default.
cmd.CommandTimeout *= 4;
con.Open();
cmd.ExecuteNonQuery();
}
Thanks very much!
EDIT
Given comments about this occurring in mirrored environments, I should indeed mention that the database in question is mirrored. It's marked in SSMS as "Principal, Synchronized", in "High safety without automatic failover (synchronous)" mode.
EDIT 5/26/11
I am seeing nothing in the SQL Server logs to indicate any problems. (I don't have access to the Windows Event Viewer on that server, but I've asked for someone to look for me.)
According to the MSDN Blog post just created today (hooray for Google!):
Microsoft has confirmed that this is a problem in the current release of ADO.NET. This issue will be fixed in ADO.NET version, ships with Visual Studio 2011.
In the meantime, we request to use the following workarounds:
Increase the connection string timeout to 150 sec. This will give the first attempt enough time to connect( 150* .08=12 sec)
Add MinPool Size=20 in the connection string. This will always maintain a minimum of 20 connections in the pool and there will be less chances of creating new connection, thus reducing the chance of this error.
Improve the network performance. Update your NIC drivers to the latest firmware version. We have seen network latency when your NIC card is not compatible with certain Scalable Networking Pack settings. If you are on Windows Vista SP1 or above you may also consider disabling Receive Window Auto-Tuning. If you have NIC teaming enabled, disabling it would be a good option.
The post itself is an interesting read, talking about a TCP/IP connection retry algorithm. And kudos to all the folks who said "hey this looks like it's related to mirroring..."! And note the comment about this being "because of slow response from SQL Server or due to network delays".
UGH!!!
Thanks to everyone who posted. Now we must all ask for a patch to the .NET Framework (or some other ADO.NET patching mechanism), so we don't have to wait for (and buy) Visual Studio 11...
Connection timeout is a different thing than command timeout. Command timeout applies to situation when you have connection established, but due to some internal reasons server cannot return any results within required time. Default command timeout is 30 seconds.
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout.aspx
Try to specify connection timeout in the connection string. Default value is 15 seconds what may be the reason of the issue you see.
You can also specify connection timeout in code:
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectiontimeout.aspx
I get this every once in a while on this old database server that we have (coming up on 10 years old now). When it does happen though it's because something is hammering that thing with connections/queries constantly. My guess is that you'll find that when it happens the database server is under load (or a high number of connections or something along those lines) Anyway, in my experience if you can optimize the code, optimize the database, getting a beefier database server, etc. all helps. Another thing you can do, which Piotr suggests, is simply up the timeout for the connection. I'd still go through and optimize some stuff though (should help in the long run).
I have been able to somewhat reliably reproduce this problem. I have a service that when a processing job is requested it kicks off processing in a new appdomain / thread. This thread will execute 10 to 16 database queries simultaneously. When I run 30 of these jobs one after another then a random one or two of the jobs will crash with the timeout error.
I changed the connection string to turn off Connection Pooling with Pooling=false and then the error changed to the following. This gets thrown 3 or 4 times inside an aggregate exception, since the connections are happening inside a Parallel.For
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket()
at System.Data.SqlClient.TdsParser.ConsumePreLoginHandshake(Boolean encrypt, Boolean trustServerCert, Boolean& marsCapable)
at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity)
at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, SqlConnection owningObject)
at System.Data.SqlClient.SqlInternalConnectionTds.LoginWithFailover(Boolean useFailoverHost, ServerInfo primaryServerInfo, String failoverHost, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, TimeoutTimer timeout)
at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, TimeoutTimer timeout, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
at Tps.PowerTools.CoreEngine.V5.DataAccess.DataContext.ExecuteQuery(PtQuery query, ValueStore`1 store, String readerDescription) in C:\SourceCode\Tps.PowerToolsV1\Trunk\Libraries\CoreEngine\CoreEngine.V5\DataAccess\DataContext.cs:line 326
at Tps.PowerTools.CoreEngine.V5.DataAccess.DataContext.<StockHistoricalData>b__15(PtQuery query) in C:\SourceCode\Tps.PowerToolsV1\Trunk\Libraries\CoreEngine\CoreEngine.V5\DataAccess\DataContext.cs:line 302
at System.Threading.Tasks.Parallel.<>c__DisplayClass32`2.<PartitionerForEachWorker>b__30()
at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
at System.Threading.Tasks.Task.<>c__DisplayClass7.<ExecuteSelfReplicating>b__6(Object )
Optimizing the queries you are executing on the remote server will always help. Time each query and look for long running ones. If you are just doing reads then use the (NOLOCK) hint on the SELECT statements. This was a life saver for me. Just read up on it to make sure it is appropriate in your application. If you have access to the remote database make sure the indexes are not to fragmented. This will cause a major slow down in query execution. Make sure indexes are rebuilt/reorganized as part of the SQL maintenance plan. Add new indexes where appropriate.
Extending the timeout may make matters worse. If you let queries run longer then, potentially, more queries will time out. The timeout is there to protect the server and other clients accessing it. Bumping it up a little is not a huge deal but you don't want queries running for a long time killing the server.