I have created a new "Database" project in Visual Studio 2013. I have set the Target platform to "Windows Azure SQL Database". The project is nearly empty, with the exception of one .sql file to create a Schema.
When I try to publish the project, it takes several minutes and ends with:
Creating publish preview...
Failed to import target model [database_name]. Detailed message Unable to reconnect to database: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
I have tested the connection string, and it works.
What do I need to do to publish to Azure? Thanks.
Like Hesham mentioned in the comments, I also had this issue with the new Basic tier of Azure SQL Database. Switching the tier to Standard S0 size fixed the issue. So if you're having issues with the Basic tier, try scaling up to publish, then scale back down when you're finished.
Check this answer from MSDN forum, worked with me perfectly!
In order to change the command timeouts used in Visual Studio 2013 you
will need to change the following registry setting:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\SQLDB\Database\QueryTimeoutSeconds
Source:
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/7e869f10-529b-41af-b54f-709a420308f6/publish-database-to-a-new-basic-scale-db-from-vs2013-times-out?forum=ssdsgetstarted
I had experienced the same problem and was able to resolve it by changing the 'Connect Timout' value to 0 in the 'Publish Database' dialog.
In the 'Target database connection:' field, click 'Edit...'.
In 'Connection Properties' dialog, click 'Advanced...'.
In the 'Initialization' section, set 'Connect Timeout' to 0.
Link to screencapture...I don't yet have enough points to publish an image. :)
My project had been taking 2-3 minutes before failing with the timeout. After the setting change, it successfully published within a minute.
I hope that helps.
Related
All of a sudden one day (on my DEV PC) my Microsoft SQL Server 2012 instance (installed as instance name "SQL2012") would not start (all my other installed instances did). Trying to start it manually under Services failed. I don't recall making any recent changes prior to this. The cause of the failure was a mystery.
On inspecting Event Viewer, under System it showed a rather amusing error message [emphasis mine]:
The SQL Server (SQL2012) service terminated with the following service-specific error:
WARNING: You have until SQL Server (SQL2012) to logoff. If you have not logged off at this time, your session will be disconnected, and any open files or devices you have open may lose data.
checking under Application Event Log, I found these 2 error messages (preceded by a number of MSSQL$SQL2012 informational messages):
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 200, state 7, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
followed by:
Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.
Fearing having lost my system databases (and not having a backup of them to restore - who makes backups of their system dbs anyway??) and needing to access the instance, and attached databases - I was willing to try anything. Even the possible restore of the system databases: Restoring the SQL Server Master Database Even Without a Backup - but that looked quite complex.
Fortunately, I was eventually able to start the instance (thank you to this answer: https://stackoverflow.com/a/59676743/4993856 which I trusted, because Pinal Dave also mentions that particular switch in: SQL SERVER – Script level upgrade for database ‘master’ failed because upgrade step msdb110_upgrade.sql encountered error 926, state 1, severity 25) if I ran:
net start mssqlserver$SQL2012 /T902
This pointed to some issue with the upgrade script... (Remember SQL is installed with instance name: SQL2012, hence the mssqlserver$SQL2012 used above for the named instance).
After some more searching I discovered this post: Installing service pack / cumulative update on SQL Server 2016 / 2017 breaks database engine (not exactly the same SQL version as mine) which pointed to the following possible Region Settings setting (Control Panel [when viewed by 'icons'] > All Control Panel Items > Region > Administrative > "Change system locale..."):
"Beta: Use Unicode UTF-8 for worldwide language support" in Region Settings
THAT WAS IT!!! After de-selecting that option (and possibly restarting my computer), the MSSQL Server 2012 Instance started up without any issue, and I was able to access all my previously attached databases.
I assume the pending upgrade scripts ran successfully. Thinking back about it now, it is possible that I agreed to installing a SQL Update, and never bothered to test access to the instance afterwards.
I also don't recall exactly why I chose to enable that specific setting under Region Settings, possibly due to some Linux compatibility, but it looks like it has become defaulted 'on' in recent Windows builds.
I got the same problem SQL2017 after update Windows Patch Hotfix3391(KB5001228)
after restart server MSSQL Fail to start and event viewer shown error below
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 200, state 7, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Solution
Fix by remove Beta:Use Unicode UTF-8 for Worldwide lang.. in the Region Settings
Then it require restart server. After restart MSSQL can start as normal.
The problem is the msdb_110.sql update script, the script is a bit of a mess, with mixed tabs and spaces (wtf?).
It tries to run a couple of procedures that fail, on startup of sql-server. They fail when the code-page is 65001 (usually because the BETA utf-8 code page option has been selected) and so SQL server fails to start.
This appears to happen any time a SQL Server update is installed. I only experience this error with SQL Server 2017, not 2019
Why?
Don't know? The script is a mess.
Solution
Deselect the use utd-8 code page option
Restart the machine
Start sql server and let it run the script
(optional) reselect the use utd-8 code page option
Restart machine again and sql server
(optinal but recommended) uninstall windows, install a unix and run postgres
Two month ago I deployed a new VM in Azure. I used the pre-configured "SQL Server 2016 SP1 Standard on Windows Server 2016" with 7 GB of RAM, and I chose the offered option to make backups automatically. Only other things I changed is add it to AD and put some databases (largest of ~2 GB size of backup file)
Now the server is running a service called SqlIaaSExtension.Service which I understand is for doing these backups as well as automated patching. You can find the services description here: MS service description
The problem is, it keeps on building up memory until after some weeks the SQL Server itself fails to execute larger queries. A restart of the SqlIaaSExtension.Service fixes the problem, but this is not at all a sustainable solution.
Does anybody know a working solution other then disabling the service and loosing the functionality altogether?
My setup (german):
I have meanwhile got some Information from Microsoft:
There seems to be an error in the SqlIaaSExtension.Service which is known to MS and will eventually be fixed.
Workaround is:
A: If you don´t need the functionality - remove this service, as indicated in the service description.
B: If you want to keep the functionality - restart the service periodically. Possibly automate via Task-planner.
Updated info from MS 19/07/2017: Error is identified and should be fixed in the next 7-10 Days. A mitigation is restarting the service if necessary.
Updated info from MS 31/07/2017: Error should be fixed in Version 1.2.19.0. This can be checked from the Azure Portal under "extensions" in the VM-Menu.
I know similar questions have been asked before...
I am using SQL server 2005, with SSRS 2005 installed on the same box. (aka. production DB, Report DB/TempDB, Database engine, and SSRS all in the same box).
We have about 200 reports deployed in the box.
SSRS/DB is running on a W2k3 64-bit VM.
Now the problem...
Occasionally almost on a daily basis our users get the 'operation timeout' error (error in XML document....). At first I thought it was a report size problem, but then when I try the Report Manager URL (http://<>/reports), nothing appears on the browser. The only thing I can do is to recycle the Report server IIS pool and it will work again. Everytime when the 'operation timeout' happens, the Report Manager URL will not work, and I can't find any logs in IIS to indicate there's a problem.
I researched on the net and found that some people have put a dummy report as part of the SQL server agent job which runs every 10 minutes from 9-5 to 'warm up' the SSRS. The dummy report made a small connection to the DB on one row from a very small table. The operation timeout problem seems to have disappeared for 95% of time, but it still happens. Strange enough, when the operation timeout problem happens, I notice the dummy report job has also stopped working. In this case, I had to recycle the IIS pool, and start the SQL server job again, and then SSRS will work again (until the same problem happens next time)
The error I got from the SQL server job is:
System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host
However I am totally confused by how the IIS issue on the report server somehow affects the SSRS job. Maybe I am on the wrong track but that's bizzare.
My observation so far is if it takes forever for the Report Manager URL (http://<>/reports) to appear it is a bad sign that something has gone terribly wrong on SSRS.
I have also added a new task which call the SSRS Report Manager http://<>/reports URL using PowerShell in order to 'warm-up' the IIS but it does not seem to make much difference.
Can someone point me to the right direction? Thanks. WM
In the past, after much research, I've found memory allocation for SSRS to be the root of many issues. You can try this.
Add the following into the <Service> node in the rsreportserver.config file
<WorkingSetMaximum>4000000</WorkingSetMaximum>
The file is typically in c:\program files\Microsoft SQL Server\MSRS11.iMIS\Reporting Services\ReportServer
This sets the maximum memory available for the report which also set the minimum memory to 60% of the maximum.
https://msdn.microsoft.com/en-us/library/ms159206(v=sql.110).aspx
My eventlog is cluttered with Package "<name>" finished successfully messages; is there any way to stop these from being added to the log?
The packages in question run very frequently and are making the eventlog harder to use
This is running from SQL Server 2008 R2 (Standard)
The job properties are set with Write to the Windows Application event log - When the job fails (and sends an email to an operator and in the corresponding maintenance plan, the settings for "Reporting and Logging" are all set with nothing checked.
And the SQL Server Agent properties are set only with the fail-safe operator; by email
For the life of me, I cannot see anywhere in SQL where I can suppress the "success" messages and would appreciate help.
I have just encountered a very similar scenario.
I have a couple of packages that are scheduled frequently. Monitoring of these non-critical packages can be managed within SQL Server Management Studio itself, I have no need to log events to the Windows Application logs.
In fact the logs are now "bloating" insofar as they are filling at a far greater pace than I am happy with.
It is possible to switch package logging on or off within the SSIS package itself.
From within BIDS (Business Intelligence Design Studio), right click anywhere within the control flow and select "Logging..." from the menu that appears.
From what I have read of this, to set your own custom logging options you have to tick the option on in the "Providers and Logs" screen and then add the "SSIS log provider for Windows Event Log" provider.
Once you have done that, you can tick options on and off within the "Details" tab. The options are all unchecked by default.
In the alternative, you could set up logging to the "SSIS log provider for SQL Server" and select the items that you do want to monitor. This then logs activity to a table called dbo.sysssislog in whichever database you configure within the provider.
You can get details on SSIS package logging here: http://msdn.microsoft.com/en-gb/library/ms181205(v=sql.100).aspx
I have a simple SQL script that I execute manually from Visual Studio. It is a data generation script so I expect it to take a couple of minutes to run. But I get the following error.
Timeout expired. The timeout period
elapsed prior to completion of the
operation or the server is not
responding.
I don't want to change any global server settings to be able to run this one file. Is there any commands that I could put at the top of the file to increase the timeout for just that script/transaction?
If you use SQL Management Studio, there are two settings in the options (I'm referring to Management Studio from SQL Server 2005, which I use):
(my Management Studio is in German, so I hope I translated the names correctly into English)
You can find both in the menu under "Extras" --> "Options"
In the options, the first one is under "Query Execution", you can set the "Execution Timeout" there (mine was on zero already)
The second one (and I think this is what you need) is the first option under "Designer", it says something like "Override Timeout for table designer updates", you can check a box and put in a value there.
Some time ago, I had a problem similar to yours (timeout message when running ALTER TABLE on a large table), and I solved it by setting this option to a higher value.
Increasing the CommandTimeout property will solves the problem
i.e.
SqlCommandObject.CommandTimeout = 500000
Increase the Query timeout and Connection timeout values in Visual Studio using the procedures documented below.
Changing the Query Timeout:
In Visual Studio IDE, navigate to Tools -> Options ->Database Tools ->Query and View Designers
You can either uncheck the option Cancel long running query or change the value of Cancel after option to a higher value.
Changing the Connection Timeout:
In Visual Studio IDE, enable Server Explorer by navigating to View ->Server Explorer
In the Server Explorer, right click on the connection to SQL Server where the CLR objects are being deployed and choose Modify Connection.
Click on Advanced button on the Modify Connection window.
In the Advanced Properties window change the Connect Timeout value under Initialization section to a higher value.
http://support.microsoft.com/kb/2011805
#christian answer did not work for me (changing the settings in SQL Management Studio).
Biswa answer worked for me. I will include code to clarify
SqlCommand cmd = new SqlCommand("MyReport", conn);
cmd.CommandType = CommandType.StoredProcedure;
cmd.CommandTimeout = 60; /* note default is 30 sec */
SQL Server will wait indefinitely before returning to the user. More than likely there was a client side timeout property set. For example you can set a timeout property for the ADO command object.
Cheers, Andy.
Never mind, I can run it fine with SQL Management Studio.
Just wanted to clarify specific steps for Microsoft SQL Server Management Studio 2005... 'Designer' defaults definitely need to be adjusted even if it is set to '0' in 'Query Execution' section as 'Designer' vars override the 'Query Execution' settings.
Open Microsoft SQL Server Management Studio 2005
Tools >> Options
Expand 'Designers'
I've found setting 'Transaction time-out after' to 120 has worked fine for updates to tables with several millions records.