Once I thought it would be a great idea to set this field to the database I am working mostly with. I was wrong. Since this database is dropped and restored rather often, each time I am forced to reconnect after the drop.
I have found some recommendations, like setting this value via sql command, but nothing works.
Reset All every time is not option cause I am not thinking about it so much and this is annoying too.
Does anyone know where this value is stored to try to unset it: master DB, registry, some file?
Why does MS add a feature to change something without possibility to reset it back? (rhetoric)
Edit:
Have uninstalled SQL Server, though a lot of crap remained in the system:
Uninstalled all of them, installed SQL Server from scratch, this issue remains...
I believe if you select the database and press delete, that clears it down. Connect, then next time it should go back to default. At least it does on SSMS2017 - haven't got older versions installed to check.
OK
Found a solution.
Needed to rename/delete file:
C:\Users\(USER)\AppData\Roaming\Microsoft\SQL Server Management Studio\12.0\SqlStudio.bin
https://social.msdn.microsoft.com/Forums/en-US/75d6c722-ddbe-4714-b954-763a496f6f63/how-to-unset-default-value-in-8220connect-to-database8221-in-ssms?forum=sqlgetstarted
https://serverfault.com/questions/278582/ssms-where-does-sql-server-store-its-server-names
Related
I'm maintaining a project using Microsoft SQL Server 2016 (SP1) (according to this script) which heavily depends on recurring jobs (mirroring certain external db's and so on).
Especially the mirroring jobs are essentially based on SSIS packages which define a datasource, then execute a hardcoded SQL query and afterwards store the results in the specified destination.
Unfortunately the source databases where moved to a different domain and thus aren't accessible via the previous url.
My issue right now is that I simply have to change the source destination url but I'm not able to do that. There are plenty of ways to 'modify' SSIS packages but none of them seem to work with me.
What I managed (and seems the most promising) to do is to open the 'Integration Services...' part of my db, export the jobs to my desktop, modify them with Notepad and reimport them. And they seem to work if I execute them separately. But as soon as I try to execute the packages via SQL Server Agent it fails screaming:
Description: Failed to decrypt protected XML node "DTS:Password" with error 0x8009000B "Key not valid for use in specified state."
Does somebody know whats going on here and how I'm able to solve this? No password or username changed, only the connection string.
Is it even possible to manage a package like that?
Thank you for your help!
After further investigation I detected that even a newly created job didn't run properly. It was kind of strange that a package would run without any issues while directly executed but not via the SQL Server Agent, so I assumed it may be a rights issue and it was!
Somehow the Server Agent wasn't allowed to decrypt (although I never changed the executing user of a step) the password anymore.
I was able to work around my issue by simply creating each SSIS package again (some click hell but ok) but this time I secured 'sensitive data' with a password instead of the users key.
Afterwards I had to change each job step with a reference to to the damaged ssis packages and obviously type in the new passwords.
Seems to work again.
Thanks anyway
I am tearing my hair out because I was working on some SQL scripts and I executed them to ALTER stored procedure, however when I came in this morning I have lost all my work, it was showing the previous day's script. Somehow it didn't save even though I watched it Execute Successfully Completed!.
Now I thought that using Microsoft SQL Server Management Studio v17.7 there will be an auto recovery temp folder with SQL files somewhere, and from looking online its states to go here; C:\Users[User]\Documents\SQL Server Management Studio\Backup Files\Solution1\ and you will see Autorecovery.sql files lots of them.
However this is completely empty, and I got no idea where clever Microsoft has moved this new location too or removed it all together. I went to settings in my SQL studio under Tools->Options->Environment->AutoRecover and both are ticked for "Save AutoRecover Info every 5 minutes" and "keep autorecover info for 7 days". Which tells me it is somewhere on my PC.
I then thought that I might have lost my work and though it would be a good idea to test this scenario on some new scripts and guess what the folder path still shows empty whilst using MSSMS so I got no idea how to utilise this auto recovery feature for the future.
Any ideas.
Try searching in visual studio directories if you have it installed :
C:\Users\<your_user>\Documents\Visual Studio <your_version_visual_studio>\Backup Files\Solution1
SSMS 2017 seems to just keep the recovery files in %TEMP%\ (with name ~vsXXXX.sql)
I have realised the only way to make sure you are safe is to have a folder specified with all your scripts stored there.
This way the autosave only works when you have saved the file prior not unsaved files, so it will be a case of Save + Execute.
I have lost my work for now, but this is why people learn from there mistakes.
Studio management 2014
This is becoming insanely frustrating and completely random. We cannot work anymore on the SQL because any small action we do will lock SSMS and will force us to end task.
In the middle of the work a popup appears: "SSMS is waiting for an operation to complete. bla bla bla" with two options: SWITCH TO and CONTINUE WAITING.
None of them does anything, not clear which operation is it talking about.
This happens when trying to open a table, a view or even pasting into a query window. When typing the query manually it doesn't happen!
Ending task and reopening the SMSS will immediately result in the same.
We tried to:
Restart SQL server
Right clicking in the taskbar (Someone suggested that)
Using SSMS from another network computer
Running select * from sys.sysprocesses where blocked<>0. there were no results.
Because of point 3 we assume that the problem is not in the SSMS, but in the SQL instance?
Last time it was resolved by itself, the next time I connected after a day.
Please help, we wasted hours here.
Thanks
I think that ending task of RDPclip on the remote computer solved the issue.
I will see when this happens again if doing it resolving it.
I'm new to using SQL server and had queries saved in OneDrive. When I tried accessing them I got the same pop up and had to end the OneDrive task in task manager. I just save everything locally now.
Vista just finished one of its many updates. After restarting my computer I try connecting to SqlServer2008 instance with Sql Server Management Studio and I get this error:
Error connecting to '...\MSSQLSERVER2008'.
Additional information:
Login failed for user '...'. Reason: Server is in script upgrade mode. Only administrator can connect at this time. (Microsoft SQL Server, Error: 18401).
Pressing help gets me to an internet page saying there's no additional information.
Thx Vista & Updates. Anyone an idea because on the internet I can't find anything about this issue.
It appears This Guy was having the same problems as you and his only suggestion was to wait a few minutes before trying to log in again.
I have yet to see any type of Microsoft documentation about this, nor have I seen any forum posts which came to any sort of resolution concerning the same problem.
Check your event viewer. I had the same problem and found that (in my case) it was looking for a directory that didn't exist to perform an upgrade script. NO hint that there was any sort of problem in the dialog, but the event viewer showed clearly what the problem was.
jim
I had the same problem. Waiting until update was done did not help. Solution was, (after checking Windows eventlog) to set the folder rights. SQL-Express had no rights on the database folder, why ever. Something has mixed up the rights during the upgrade from WinXP to Win 7. That was it.
Adding a comment to this page since this is the top Google result for "script upgrade mode". It seems that a number of things can cause a SQL Server DB to go into this mode. In our shop we've run into these two cases in the past months:
Log shipping - Can't recall at what point of the process exactly the DB went into this mode, iirc it was when bringing it back up. The solution was just to wait it out.
Hard drive full - The DB went into this mode when it ran out of space. We're currently clearing up the drive, will come back with an update if waking it up turns out to be challenging.
Update: After freeing up disk space, it was a simple matter of setting the DB "Offline" and then "Online" to bring it back up.
We had the same issue, but needed to know what was going on in the background.
The db's were put into recovery mode, hence they had to recover. To assist we went to the SQL Server error log located where the system files (normally master, model, msdb...) are located, but under the log folder. In the ERRORLOG, we did a find on the word recovery and could watch the db's percentage recovered. Everything recovered normally, but it was much longer than expected.
The Reason for this is that the system reboot happens with important\necesssary softwares loaded and does all other operation later so that the booting happens faster.
Here in your case, the sql booting is happening as the start of SQL is not needed for system to start. I hope you are aware of DAC account(Dedicated Administrator Connection, Link) who has seperate connectivity and has ability to resolve issues even the whole SQL server is not responing. The SQL server is asking you either to wait or open the SQL with DAC account and stop the SQL update.
Solutions:
1) Wait until backround update completes
2) Open SQL using DAC account and kill all running processes
I've long been a fan of Stored Procedure Keyboard Accelerators, as described in this article. When we moved from SQL 2000 to 2005, though, and from Query Analyzer to Management Studio, the handling of the arguments changed. In QA, comma-separated arguments were automatically read as two separate arguments. In SSMS -- at least for me -- it's being read as one argument, with commas in it. Similarly, if I pass in a single argument with single quotes in it, I get a syntax error, unless I escape the quotes (' -> ''). In the article linked above, the author implies that this should not be the case for SSMS, but even with her exact example, comma-separated arguments are still being interpreted as one argument on every SSMS installation I've tried it on (3 of them), running against every SQL Server installation I've tried (4 of them).
E.g., typing the following into SSMS,
Person,4
then selecting it and running the shortcut, I get the error message "Invalid object name 'Person,4'.
Does anybody have any idea how to fix this? Does anybody even use these shortcuts? I've Googled this problem several times over the past two years, and have had no luck.
Edit: May be an issue with a specific build of SSMS. I have a follow-up post below.
I had never tried this until I read your question and then read the article you referenced, so take this with a grain of salt.
That said, I am able to get the process to work on my computer using SSMS, and I am also able to duplicate the error you described.
To get this to work as expected I created the sproc in the master database, assigned the keyboard shortcut and restarted SSMS. I then typed the databasename.schema_name.table_name in single quotes followed by a comma and then an integer value (the sproc I tested was the GetRows sample in the article). I was still connected to the master database.
This worked without incident.
To get the same error that you mentioned, I removed either the reference to the schema name or database name and received the same error you did.
Perhaps you need to add the database name and schema name before the table name?
Tim's suggestion didn't solve my problem on my development PC, but it did convince me to try again from a different PC. When using a different PC's SSMS to log into the development PC's database and trying exactly what Tim describes, I'm having the same behavior Tim describes.
I was also able to re-replicate the argument parsing issue on the other PCs I had tried in the past. I'm hoping Tim can let me know what's the version and build number on his SSMS installation, because my current theory is that the problem is just from the specific build that my coworkers and I have on our dev PCs -- the version string is "Microsoft SQL Server Management Studio 9.00.1399.00". All of our installs of that version took place well over a year ago, so I don't know that I can trace back what disk it's from.
The one that is NOT having the problem is actually our development server, which has "Microsoft SQL Server Management Studio 9.00.3042.00" installed. I don't know if this might be something I can make go away by patching or something, but it currently looks like 1399 reads the entire selection as a single argument, while 3042 does some pre-parsing. I've also recently found that when I pass in a string that contains "--" (comment token) in 3042, everything after the "--" is ignored, while in 1399, it's all included in the first argument.
I am using SSMS version 9.00.3042.00 as well, which probably explains why it is working on my machine.
Agree with Tim. I have just upgraded to SQL Server 05 sp2 and I confirm that this bug gets fixed.