When I go to File > Open > File and select a .sql script, or even when I drag a .sql file into the SQL Management Studio Express window, it opens the script in Notepad which is totally useless when I want to run the script.
Since this is on an external server (Windows 2003 Server), I end up having to disconnect from RDP, disable the local clipboard, re-connect and then copy-paste the script's contents from Textpad in order to run it.
I've checked the options menus but can't see anything relating to Notepad, not even in the "external tools" section. Any ideas why it would be doing this?
Please note: I have checked the file association for SQL scripts and it is set to SQL Management Studio Express.
Ran into this this morning. Turned out to be an encoding issue for me. I opened the script up in UltraEdit and I noticed that it was showing the encoding to be U-DOS instead of DOS. I ran the Unicode to ASCII conversion (also in UltraEdit), saved the file, and now Management Studio is opening up the files correctly.
I encountered this too - thanks NFrank for spotting the issue:
This was caused by opening the script in TextPad and accidentally saving as Unicode. The issue is not related to file associations.
The solution: Open in Notepad (or TextPad) - Save As... and select Encoding: ANSI
UPDATE:
In SQL Management Studio,
Go to File > Open > File,
Highlight a SQL file,
Click the down arrow on the Open button.
Select Open With...
Select SQL Query Editor
Press the Set as Default button.
Matt
The first thing I'd check is to see if the application associated with SQL files on that box is Notepad.
Related
I am performing SQL Server schema comparison using Visual Studio 2017. I am pressing on "Generate script" button of Schema Compare utility and see the message
"Update scripts generated successfully"
However, I am unable to see the generated script. Any idea where this went or if it failed?
According to this page "The generated script appears in a new Transact-SQL Editor window".
When this didn't work for me, i closed all open windows other than the schema compare window and re-checkmarked all differences in the list (i had un-checked some). After doing this and running "Generate Script" again, Visual Studio did actually open a new window with the script (The filename was "C:\Users\me\AppData\Local\Temp\MyDbName_Update1.publish.sql").
I've noticed that if SSMS is running , SSDT won't generate Schema Compare script. As soon as I close SSMS and try to generate script again SSDT creates one successfully.
Instead of direct compare from connection string, generate schema file and then compare that file
do this steps:
in visual Studio Go To Sql Server Object Explorer
Right Click on database name
Select Extract Data Tier Application
select location for file save
select Schema Only
deselct all checkbox option or check as your compare requirement
do the same for both source database and target database
then
when compare schema select option Data-Tier appication file option
Installation of SSMS 2012 alongside any other existing SSMS installation, such as SSMS 2008 R2 has a problem with setting the default program for opening .SQL files to the new SSMS 2012 version.
Dragging .sql file to the query window works successfully. However, when a user double clicks on the .sql file a new instance of 2008 R2 can open as the .sql associated entry. Changing with Default Open With makes no difference when doubleclicking on new files. Additionally, altering the command line script for the opening can perhaps achieve changing the .sql to opening in SSMS 2012, but it still causes repeated instances of ssms instead of using the existing instance (causing additional load and memory usage).
Adapted from this post on how to how to fix .sql file not opening with SSMS 2008, you should start by opening up the registry (regedit)
Go to HKEY_CLASSES_ROOT\.sql and change the default value to ssms.sql.11.0 (SSMS 2012 is v11 of the product). This tells your computer the application string it should look for when trying to open files of type .sql
The registry takes that name you just entered and then looks up what to actually go do in another registry setting.
Go HKEY_CLASSES_ROOT\ssms.sql.11.0\Shell\Command and change the default value to:
"C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe" "%1" /dde
Turn your computer off and on again for good measure.
If it still doesn't work for whatever reason. Right click on any SQL file. Go to Properties and click to change the file it opens with. You may have two SQL options available. Try one then the other.
To change to default entry I utilized an application that displayed the DDE (dynamic data exchange) values. I personally used FileTypesMan.
I then changed the command line for SSMS to:
"C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe" /dde "%1"
The reason a new instance is always opened with editing seems to be that windows needs to associate the file with a program so that it can identity if the existing program is running and use this instance. This seems to be achieved by using DDE. /dde indicates that the command line should use DDE. "%1" passes the first string (ssms.exe path) to the DDE protocol for usage as a parameter.
DDE Message: was kept at the SSMS 2008 R2's value I found: Open("%1")
DDE Application: Change the Application to ssms.11.0
Why? This was the difficult part. Where is this found? I could not find a tool for displaying the DDE application name. What I found was when I reviewed the registry editor that sqlwb.sql.9.0 is the entry to open a new .sql file with 2008 R2. This matched the registry entry for sqlwb.9.0 that SSMS 2008 R2 entry was showing before I started making my changes in FileTypesMan. I removed the .sql and found that the HKEY_CLASSES_ROOT had an entry for ssms.sql.11.0 .
= File association now set to new installation, and if SSMS.EXE is open, it should use the existing instance with no additional work.
Tip: To further speed up the initial load if you don't have it open, you can use other command line options on the load. Just go to the RUN dialog and type: ssms.exe -? for a list of startup parameters. I personally use -nosplash to eliminate the splash screen load.
Additionally, I use SSMSBoost, the single greatest tool I've had to help with using SSMS daily (basic code formatting, snippet w/cursor placement, preferred connections setup, full keyboard shortcut programming (along with the option for multiple steps in once shortcut, ie basic macros". Andre and his team are extremely responsive to new ideas in their forum, its very much developers helping improve other developer's life.
For SQL 2014 you can use the following *.reg-file (for 2012 replace the 12 with 11 and for 2016 (I guess) with 13) :
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\sql_auto_file]
#=""
"EditFlags"=hex:00,00,00,00
"FriendlyTypeName"="SQL"
[HKEY_CLASSES_ROOT\sql_auto_file\shell]
[HKEY_CLASSES_ROOT\sql_auto_file\shell\open]
[HKEY_CLASSES_ROOT\sql_auto_file\shell\open\command]
#="\"C:\\Program Files\\Microsoft SQL Server\\120\\Tools\\Binn\\ManagementStudio\\Ssms.exe\" /dde \"%1\""
[HKEY_CLASSES_ROOT\sql_auto_file\shell\open\ddeexec]
#="Open(\"%1\")"
[HKEY_CLASSES_ROOT\sql_auto_file\shell\open\ddeexec\Application]
#="ssms.12.0"
[HKEY_CLASSES_ROOT\sql_auto_file\shell\open\ddeexec\Topic]
#="system"
I had this same issue. Using "restore file associations" in ssms 2012 had no effect. I was able to resolve it by right clicking and choosing "open with" -> choose default program. Now I know you've said this didn't work, but there is a trick. Rather than selecting the pre-provided icon for ssms 2012, choose browse and go to c:\program files(x86)\Microsoft SQL server\110\tools\binn\managementStudio\ and click on ssms.exe. Click open, click ok. Once I did this, ssms 2012 was the default, and double clicking more .sql files loads into tabs in the same instance.
Another solution: https://stackoverflow.com/a/24945327/813599
I went looking for a more proper way to link to other Q/A's and couldn't find it after 15 minutes of searching... would love to be educated and will edit this out if so.
I was having a similar but slightly different issue. I wanted to open .sqlplan file in a new tab in SSMS 2014. I tried all of the above but none of them worked.
Looking at the registry, I found that ssms.sql.12.0 has "DdeExec" node, while ssms.sqlplan.12.0 does not.
enter image description here
So I export the "DdeExec" node from ssms.sql.12.0 and rename sql to sqlplan, then import it back in. After that, I was able to open .sqlplan file in a new tab.
Here is the registry file:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\ssms.sqlplan.12.0\Shell\Open\DdeExec]
#="Open(\"%1\")"
[HKEY_CLASSES_ROOT\ssms.sqlplan.12.0\Shell\Open\DdeExec\Application]
#="ssms.12.0"
[HKEY_CLASSES_ROOT\ssms.sqlplan.12.0\Shell\Open\DdeExec\Topic]
#="system"
Management Studio 18:
"C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe" /dde "%1"
I know how to add additional extensions to SQL Server Management Studio, to have them treated just like .sql files. But, when opening them, a new instance of Management Studio is created.
I also see numerous issues posted about double clicking on .SQL files and getting them to open in the existing instance of SQL server. This already works for me.
What doesn't work is the additional extensions I have added. I'm using .PRC. All of the fixes propose changing various registry settings, all which are related to the default .sql extension.
I don't see see how any of these fixes can be applied to make other extensions work or if there is anything else I can do to solve this?
EDIT:
What i've done so far...
Copied over all the same settings from [HKEY_CLASSES_ROOT.sql] to [HKEY_CLASSES_ROOT.prc].
Checked all the settings mentioned in the article on sql server central to fix this issue for .SQL extensions.
Configured SSMS file type .PRC with editing experience "SQL Query Editor".
I even tried creating a batch file to open the file for me:
"c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\ssms.exe" /dde %1
Even the 4th thing I tried opens a new instance, although this is the same call that is configured in the registry for sqlweb.sql.9.0.
I resolved problem of opening PRC file by double click. I simply exported this key from regedit
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.sql
Modified this file to look like this
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.PRC]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.PRC\OpenWithList]
"a"="ssms.exe"
"MRUList"="a"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.PRC\OpenWithProgids]
"ssms.sql.11.0"=hex(0):
"ssms.sql.12.0"=hex(0):
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.PRC\UserChoice]
"Progid"="ssms.sql.12.0"
And applied it over registry. The original PRC key I backuped and removed from registry before I applied that new keys. Now PRC file is opened by double click on PRC file in opened instance of SSMS.
But highlighting doesn't work still for me :(
You seem to be going through a lot of hassle to deal with your source control system. Have you considered making your source control system recognize a different extension for procedures, tables, views, etc. which will prevent you having to make these registry changes on every developer's computer?
.proc.sql -> stored procedure
.view.sql -> view
.fn.sql -> function
etc. etc. Surely your source control system can handle longer extensions that contain ., and now Management Studio will behave properly with all your file types.
I've been searching for a "definitive" solution to this for a couple of hours now and can't find out exactly what the problem is so am hoping someone can point me in the right direction.
I'm trying to create a script for a database (an MDF file DB) on a remote machine and use it to create the same database locally. I've got Visual Studio 2010 on both machines so used the Database Publishing Wizard to generate the script.
I next created a blank DB in Visual Studio locally (another MDF file DB) and selected to create a new query. I've pasted the copied script in but when I try and run it I get dozens of "incorrect syntax near GO" errors. I'm not sure how many in total as the alert pop-up goes off the bottom of my screen. It would seem to be a lot though.
I trimmed off all but the very top of the script and I still get the same errors with it. It now looks like this:
SET ANSI_NULLS ON
GO
I still get the "incorrect syntax near GO" error with this.
Is there something inherently wrong with the scripts this tool generates or am I doing something wrong with it?
The remote DB is 2008 R2 and my local is just plain 2008, hence why I don't just copy the MDF file across.
If anyone has any suggestions, they would be most welcome.
From the docs:
GO is not a Transact-SQL statement; it
is a command recognized by the sqlcmd
and osql utilities and SQL Server
Management Studio Code editor.
Either use such a tool to execute the script or omit the GO commands.
I ran into the same problem recently and found the right answer to it (I think).
If you create a query in some random editor other than SQL Server Management Studio Code editor at the end of a line you may get a CARRIAGE RETURN (\r) character instead of a CARRIAGE RETURN + LINE FEED (\r\n). And even if you hit the DEL key at the end of the line and then Enter it doesn't change.
Use Notepad++ to replace CR (\r) for CRLF (\r\n) - keep the order, it's important!
I'm used to double-clicking *.sql script files to open them in SQL Server Management Studio. I recently upgraded to Win7, and now when I double-click a script file, SSMS opens with an empty environment. I can then use File/Open or File/Recent Files to open my script, but I would much prefer for it to just open whatever I double-clicked on like a normal application would.
Any ideas what's going on?
BTW when I double-click a script from the Solution Explorer in Visual Studio, it does open it automatically just like you would expect.
I had the same problem. I don't know what caused it, but I fixed it with a quick Registry hack.
Go to HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\Command
Edit the (Default) value
It should contain something like this: "c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\ssms.exe" /dde
Add "%1" to the end
The final value will be something like this: "c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\ssms.exe" /dde "%1"
In my case the registry key that needed fixing was HKEY_CLASSES_ROOT\.sql
The (Default) had been changed to sql_auto_file... and needed to be ssms.sql.12.0 (for SSMS 2014)... presumably ssms.sql.11.0 for SSMS 2012.
All the other stuff down in the HKEY_CLASSES_ROOT\ssms.sql.12.0 path, that most other solutions tend to refer to, was fine as is.
I tried all the ideas above (registry entries, etc.) - no luck.
What ended up fixing it for me was this:
1. close all SSMS instances.
2. right click on a .sql file and select "Open With..." > "Choose Default Program"
3. Select Notepad
4. Double click on the file - it should open in notepad.
5. close notepad.
6. right click the .sql file again and select "Open With..." > "Choose Default Program"
7. Select "Sql Management Studio" again.
8. Click the .sql file it should open SSMS
9. Subsequent .sql files should open in the same instance.
Hope this helps :)
For SQL Server 2012 the reg key is different:
HKEY_CLASSES_ROOT\ssms.sql.11.0
It does it on my WinXP box too...
I agree with Josh Yeager, but I went into Control Panel > Folder Options > File Types tab and did it there.
Scroll down to SQL extension
Click Advanced button
Select "Open" from the Actions box
Select "Edit.."
Funny thing is, my "DDE MEssage" box already had a "%1" in there, but it wasn't in the Regedit value. Clicking "OK" out of everything updated the appropriate key(s) and while this is a lot of clicks, it's a better habit to get into than poking around in the registry. Fat-fingered people can get into a lot of trouble in a registry...(that's me, BTW :-D)
Oh, and like Herb Caudill pointed out, the "/dde" needs to be in the regkey but again, using the Folder Options area will handle the appropriate entries.
Run regedit and go to the following key:
Check to make sure you have tthe correct version. In my case, it is 12.0
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ssms.sql.12.0\Shell\Open\Command
Edit the default value to add "%1" to the end.
The value should now look like the following: (modify path name to to match the ssms.exe program on your pc)
"c:\Program Files\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\ssms.exe" /dde "%1"
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell]
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open]
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\Command]
#="\"c:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\sqlwb.exe\" /dde"
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\ddeexec]
#="Open(\"%1\")"
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\ddeexec\application]
#="sqlwb.9.0"
[HKEY_CLASSES_ROOT\sqlwb.sql.9.0\Shell\Open\ddeexec\topic]
#="system"
Have you installed the latest relevant SQL Server service pack?
SQL Server 2005 and 2008 need patched on Windows 7. This article is about express but the same "fix" should apply. It's common for each new MS OS.
Generally, you always have your client tools at the same build as your server installs anyway.