I'm using an application which has the ability to create a backup from an sql server, but the size of it creates an error:
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
The backup or restore was aborted.
What I am wondering is if I am able to change the time out time from Management Studio without altering the application.
And if there is no other way but to change the connecion string to the database, does adding a simple ;Connection Timeout=30 to the string solves this problem? The application is written in C#.
What I am wondering is if I am able to change the time out time from Management Studio without altering the application.
Yes, you can change the timeout in Management Studio. See this article.
does adding a simple ;Connection Timeout=30 to the string solves this problem?
No, that is the timeout when you connect to your SQL Server, not the query execution timeout.
Related
We recently upgraded our SQL server to 2016 and I turned on QueryStore to do the analysis that it provides. I'm encountering a problem where, even if the time period of the report is Last hour, it will generate a message that says "Couldn't connect to database" even when running it on the database server itself. Sometimes if I keep refreshing the report it will eventually display some data, but it's intermittent at best. I'm running SSMS 17.5 on a sql server 2016 server.
We are having a somewhat similar issue with another program that connects to the database where it will sometimes not be able to connect, but every time I run my queries in SSMS, run reports in SSRS, or even use activity monitor, I never see any connection drops, so I'm not sure if it is related.
Thank you in advance for any help!
I find it works fine with the statistic set to Avg, StdDev, or Total. Max and Min give the error.
I found this happens when the query store runs out of space and gets into cleanup mode.
In database properties in SSMS try playing around with Query Store settings: for how many days it stores the query stats and does it get into "size cleanup" mode. More info on how to keep it adjusted: https://learn.microsoft.com/en-us/sql/relational-databases/performance/best-practice-with-the-query-store?view=sql-server-ver15#Configure
I am receiving a timeout error when trying to reverse engineer a SQL Server database into a Database project. We don't have any spatial indexes on the that database (I checked using this).
I don't have a timeout setting on the connection (
3/8/2016 9:46:00 AM An error was received from SQL Server while attempting to reverse engineer elements of type Microsoft.Data.Tools.Schema.Sql.SchemaModel.SqlSpatialIndex: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
3/8/2016 9:46:00 AM An exception was generated.
Unable to reconnect to database: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
3/8/2016 9:46:00 AM An error was received from SQL Server while attempting to reverse engineer elements of type Microsoft.Data.Tools.Schema.Sql.SchemaModel.SqlSpatialIndex: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
3/8/2016 9:46:00 AM Finished importing database.
3/8/2016 9:46:00 AM A summary of the import was saved to the following location: C:\Temp\Import From Prod 2\Import Schema Logs\Import From Prod 2_20160308024125.log
3/8/2016 9:46:00 AM Click Finish to continue...
Steps to reproduce the issue:
Open Visual Studio 2013
From the menu, click on "View" / "Sql Server Object Explorer"
Connect to a SQL Server (in our case, the UAT server) and choose a database
From the context menu of the database, choose "Create New Project"
Press "Start"
How do I figure out what is actually timing out? How do I fix this?
Can you increase the amount of available RAM? This exact error started showing up for me with schema comparisons between an existing db project and a local database. The problem was resolved when I shut down all of my applications except Visual Studio. This makes me think that my pc did not have enough resources to complete the task in the desired time when I have several apps open.
One option that worked for me was to increase the value of HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\NN.N\SQLDB\Database\QueryTimeoutSeconds and restart Visual Studio based on this. But, although successful, it was taking nearly 5 minutes to compare.
Later I discovered that we recently changed our build target to Sql Server 2016, but were still referencing a 2012 master.dacpac. I updated the reference to a 2016 master.dacpac and the compare now completes in less than a minute.
So, it seems that it is not possible to set the timeout for each single step in a SQL Server job (article from StackExchange).
MSDN points out that you can of course set the Agent timeout:
Sql Server Agent properties.
Set Job execution shutdown.
Questions
How does Agent time-out work?
Is there any other way (preferably by configuration) to setup the single step timeout?
Is there any other way (preferably by configuration) to setup the whole job timeout?
To answer question 2, I'm not sure if this is the best option but you could use OPENROWSET to control a single step timeout.
http://msdn.microsoft.com/en-us/library/ms190312.aspx
Just because OPENROWSET is normally used to access remote servers doesn't mean it has to be.
Probably this is similar to how agent timeout works.
You could even use this to control the whole job timeout although if you want to do it by configuration you'd have to create your own tables.
I'm not sure this is the best solution but it's a solution at least.
I am running Access 2010 FE and SQL Server 2005 BE.
I can execute pass through queries to my SQL Server succesfully by using DSNless connections.
During my testing phase sometimes I need to restore my database to get back to my original records so I can rerun my pass through queries. What I have found is when I run a pass through query, it creates an active connection on my SQL Server. I see the connection via the SQL Server Management Console under the MANAGEMENT | SQL Server Logs | Activity Monitor, select view processes. There I can see which process ID is being used and who is using it when I run my pass through query.
Now the only way for me to restore my database is to KILL the PROCESS e.g. Active connection
Now when I have my restored database in place and re-run the pass through query, I receive a ODBC -- Call Failed message box. I have attempted to run a procedure to refresh my querydefs but to no avail, I will still get the ODBC-- Call Failed message box when I click on those objects.
Now there are two options on how to fix this problem, which in either case I find not USER Friendly.
Restart my Access Application
Wait approx 5-10 minutes to rerun the Pass Through Query
I created a function to trap my ODBC Errors and this is what appears:
ODBC Error Number: 0
Error Description: [Microsoft][ODBC SQL Server Driver]Communication link failure
ODBC Error Number: 3146
Error Description: ODBC--call failed.
So if for some reason, I need to restart my SQL server or kill a process (Active Connection) on my SQL server while the Access Application is currently connected via ODBC, the objects created via ODBC will not perform properly till I execute the 2 workaround solutions as stated above.
Can anyone shed some advice on a solution? I appreciate any insight.
I asked a similar question some time ago, and never got a satisfactory answer. My original question is here: Force SET IDENTITY_INSERT to take effect faster from MS Access
There is a registry setting documented here for ACE that controls the timeout behavior:
ConnectionTimeout: The number of seconds a cached connection can remain idle before timing out. The default is 600 (values are of type REG_DWORD).
So as a third workaround (in addition to the two you already listed) you can change that registry setting to a shorter timeout (like 10 seconds). This is the approach I took in my answer. One caveat is that shortening the timeout may cause performance or other issues. Your mileage may vary.
See my full answer to the original question for more info.
up to a while ago I used SQL2k5 exclusively but recently got updated to 2008 R2. Apart from the obvious changes in Mgmt Studio, there is one quirk that's starting to be very annoying : each time a connection is dropped, I have to switch back to the 'lost' database again as it seems the conneciton automagically reconnected to the initial database again.
In SQL 2005 I simply had to press F5 twice and the first time it would give me an error saying the connection was lost, the second time it would reconnect to the database it was on before the connection got dropped and then execute whatever sql-commands it had. It did not really matter how I had gotten to that database, be it by using the dropdown-box on top, or a USE statement...
In SQL 2008 (R2) I now press F5 and mgmt studio will "eat" the lost connection silently and instead immediately reconnect to the server and execute the code on the default database or the database that I 'forced' while connecting using the [>> options] button/tabs
This happens quite a lot as I often have one tab open that kills all connections and restores the database, and another (series of) tab(s) with changed procedures, test-cases etc...
Is there some (hidden) configuration to (re)set this behaviour ???
I know I can try to add USE statements on top everywhere, or 'force' every connection directly to it's 'target' database, but bye bye for ad-hoc queries then =(
ps : doing some extra searching I'm wondering if this isn't due to the "fix" bespoken
here [connect.com]
ps: as a side note, after reconnecting the SPID on the bottom of the screen isn't updated properly either, as a result I've already been killing the wrong connection as I based myself on stale information ... yay for progress =( (**)
Anyone with better google-fu than me ? Or closer connections to Microsoft ? =)
Thx.
(**: man, I so miss Query Analyzer =)
If you register the instance you're connecting to in management studio, you can go to "Connection Properties" on the registered instance and set "Connect to database" to be the main database you use on that instance. When you are disconnected and it auto-reconnects, it will use that default database again.
Limitations:
You can only set this to one database per instance, by design.
You need to connect using that registered instance to get it to work (right click on it, then 'New Query'). If you just do a new connection without going to the Registered Servers pane, it won't apply the properties to the connection.
Certainly not a perfect solution, but perhaps better than nothing.
PS: Connect bug for incorrect spid is here. It looks like there is a promised fix in Denali
Note: rereading, I see you're already setting the database on the advanced options for your connection at times. This is no more helpful than that, of course, just prevents you from having to do it each time.