Can anyone tell me what the $#%& this is? I'm assuming its a local only issue since I can't find anything on the net pertaining to it in particular.
I've even gone through and deleted all the Data Connections in the Server Explorer and I still keep getting this dialogue over and over. It's a fresh install of VS 2012, any insight appreciated.
So basically we had some folder redirection sync issues backing up appdata and basically had to take off the permissions and kill the profile before signing back in.
In other words if you happen to run into this in my scenario of config'ing a new machine while still trying to work on the original and you're logging in as the same user and your appdata is syncing, your paths may not match. Problem solved, but took some figuring to realize the issue.
In my case, I had an icon on top right corner in VS prompting that authentication expired. I had to re-enter authentication to a Microsoft account in my case a Hotmail account.
Related
Running SSMS 18.6 causes the program to launch, hang, and then crash. There is no error message given, the program simply terminates before any action is taken and nothing is connected.
I've uninstalled and deleted all files for SSMS, Visual Studio, and SQL Complete.
I tried the 18.6 and 18.5.1 versions of SSMS to no avail.
From https://dba.stackexchange.com/questions/237086/sql-server-management-studio-18-wont-open-only-splash-screen-pops-up/237087#237087 :
I have tried copying the Interop.8.0.dll file from privateassemblies into public. No effect. The line in the config file mentioned here is already commented out in the recent release of SSMS.
From Sql Server Management Studio closes immediately after startup :
I have tried renaming or deleting the package file listed here and removed the relevant registry key. This causes SSMS not to open at all and Windows to issue an alert sound. No other effect.
From https://social.msdn.microsoft.com/Forums/silverlight/en-US/9d0e2459-eb74-46e8-a983-05ae2ba18977/ssms-crashes-on-startup?forum=sqltools :
I tried to repair .NET framework. No effect.
I was only able to install and successfully connect on SSMS version 17.9.1
I can provide Event Viewer details if anyone is willing to help me troubleshoot. I have a .NET Runtime error and two application errors- one is event name CLR20r3 and the other is APPCRASH. Happy to provide more information if needed.
While I can't speak to the exact reason it happened, I found a solution. Whatever the issue was, I discovered it was user specific and limited to my machine. Other users were able to access SSMS as normal on my machine as was I on theirs.
I happened to remember that the AppData folder exists and is just hidden, so I used an administrator account to copy that from a working user and rewrite the files in both of mine that were not used in some background process. This allowed me to once again access SSMS both as my regular user and with my elevated administrator account.
I had this same issue (it happened all of a sudden perhaps due to a windows update). I also tried all the other solutions listed above, but the only thing that worked for me was to uninstall and then reinstall version 7.9.1 like the original poster recommended.
In my case I only have 1 user on the computer, so the other user accounts being able to access was not applicable.
I created SSIS packages and used the Integration Services Deployment Wizard to deploy it out to the server. I'm manually going to the Integration Services Catalog access through SQL Server 2012 and right-clicking and executing my package.
However, the package keeps failing and I'm getting the following errors when I check the execution report's messages.
They appear to be failing on data tasks where I have script components.
Assign :Error: CS2001 - Source file 'C:\Windows\TEMP.NETFramework,Version=v4.0.AssemblyAttributes.cs' could not be found, CSC, 0, 0
Assign :Error: Failed to compiled scripts contained in the package. Open the package in SSIS Designer and resolve the compilation errors.
This answer is a more detailed version of UberDoodles answer.
In Windows Explorer.
Navigate to C:\Windows\Temp\
Right click the folder and select properties
Go to tab Security, choose Advanced
On the default tab Permissions, choose Change Permissions
For the relevant Permission entry, choose edit.
By default, I had 'allow' checked for Traverse folder / execute file, Create files / write data and Create folders / append data.
Also check 'allow' for List folder / read data and Take ownership.
Press OK, the window closes
Press Apply and confirm anything you need.
Additionally, the logged in user had already Full control, but when I changed this for the entry 'Users', it worked for me.
(based on microsoft file/folder permissions).
I had the same problem today, just on SQL 2016.
For me it helped to change the target server version in Visual Studio project properties from SQL Server 2012 to SQL Server 2016.
I was investigating the same issue, and I came across a solution here :
https://social.msdn.microsoft.com/Forums/vstudio/en-US/73e67f3a-c575-4c73-a71d-ed7a2aeabb50/csc-error-cs2001-source-file-cwindowstempnetframeworkversionv40assemblyattributescs?forum=msbuild
Basically, the account which the package runs under needs to have full permissions to the C:\Windows\Temp\ folder, so that it can create temporary classes.
It worked for me :)
I had the same problem. I first used Eric G. response and added the List and Read permission to the c:\windows\temp. After I got everything working I went back and removed that permission. I then redeployed my solution from Visual Studio, this time designating the deployment target as SQL Server 2014 (which was the environment I was using) using Martin's solution. I then reran the process, and it worked with the List and Read removed.
I kept it using Martin's solution, as I don't like to have special permissions granted if I don't need them.
Good Luck
[Visual Studio 2017 15.9.16]
I just restarted Visual Studio as Administrator and the issue disappeared, which confirms the permissions idea of the answers above but spared me all work.
It's not a quirk though, as per this question and its answer you need that kind of permission for several tasks, like profiling and debugging under certain conditions.
For the sake of completeness, this blog says you might incur in some security contraindication if run VS as administrator when opening third-party solutions.
We are working on a remote desktop server 2008 R2 Sp1 that has all the updates.
Yesterday i wanted to install an office 2013 MAK professional plus next to the allready installed office 2010 standard. For that i had chosen for a custom install and clicked the radio button that told me to leave the previous version (office 2010).
After the installation of the office 2013 the office 2010 became corrupted by a not know reason so what i have done is remove everything of office and just installed the office 2013 (all in install modus -> change user /install).
We had some GPO enabled that had influence on the office 2010 installation and i just turned these of. On the same time i have made some changes in my default GPO to make a shortcut on every remote desktop of all office programs.
Last thing i have done yesterdag was expand the hard drive volume from 100Gb to 250Gb and rebooted that server a last time.
This morning all of the sudden it is not possible anymore to start a remote app (not only the office remote apps but also the ones made before). When we start the remote app the starting screen is just disappearing after a while. When i click on the detail button i see it is loading the GPO's and then gives "preparing desktop" but right after that it is "logging off".
The strangest part about this is that the user can log on with his name on the remote server -> remote desktop without any problems.
How can this be possible? There are toppics i have found over the internet but none of them are answered..
When i take a look at the event viewer i see some errors appearing when someone click on the remote app but i dont know if it has anything to do with that..
A timeout (30000 milliseconds) was reached while waiting for a transaction response from the UmRdpService service.
User Logon Notification for Customer Experience Improvement Program
User Logoff Notification for Customer Experience Improvement Program
Hope to find some help here!
Came out that it had nothing to do with my actions yesterday but indead because of an update released yesterday.
Found the exact KB trough the website of serverfault. After removing the Update KB3004394 and doing a reboot the problem is solved! Just had to exclude this update the next time till there is a fix for this. Special thanks to Gordon who posted this!
I was able to remove this update and reboot the affected server.
A couple of things to note:
Immediately upon reboot, same issue remained (oh crap)
Decided to remove same KB from guest computer and rebooted
Upon reboot, same issue remained
While researching issue further, about 10 minutes lapsed and I decided to try it again and it worked.
I can't explain the delay in it working, but I was able to resolve it with just that one KB removal.
Sometimes I miss the 1 or the F2 in my computer keyboard when using SQL Server Maganement Studio, that causes my SQL MS to hang and the I have to close it with the Task Manager, but many time I loss a lot from the queries I was working on, so I would like to fix this problem,
Maybe someone here has the same problem.
Microsoft Document Explorer
The Application Data folder for Microsoft Document Explorer could not be created
Right click on the SSMS program (in the start menu / desktop) and select "run as administrator". Do whatever you do to cause SSMS to hang, quit and re-run as normal user. This should remove that warning.
After many intents to solve this problem, I received this message:
External help is not available because Microsoft Document Explorer is
not installed. To view help, change your Help preferences to use the
Integrated Help Viewer or Install Microsoft Document Explorer
I tried to do it at Tools->Options->Help->General->
Show Help usaing: Integrated Help Viewer
Search Result per page: 20
Show Topic abstracts: checked
Reuse Topic window: checked
Highlight search termn: checked
I had to tried many times until SSMS wanted let me to do it.
Now the problem has been partially solved, when I press F1 the SSMS does not hang, but when I still try to change something in the help options, then chunks..
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