Change SSMS Default File Location (Specifically Templates) - sql-server

TLDR: How do I change the default location for SQL Server Management Studios 2014 without uninstalling and reinstalling?
I recently installed SQL Server Management Studio 2014, and the default file locations aren't where I want them. I was able to change the default query location and default project location through Tools -> Options, but I cannot for the life of me figure out how to change the template location. Even if I delete the folder, every time I run SSMS, it creates a new folder where it used to be.
I'm guessing I just missed an option somewhere (possibly the XML section?), but any pointers would be appreciated.
In case it matters, I want to move the default location from "Documents/SQL Server Management Studios" to "Documents/Programming/SQL Server Management Studios"
Edit: I already changed the file path on the Import and Export settings, and the Query Result -> SQL Server tabs.

Don't know about moving the entire location for SSMS, but if you are looking to modify the core templates that keep reloading, see below.
I have always kept my go-to scripts in the Templates and to keep things clean, I've always first bundled all the shipped templates to a separate folder. You have to do this not only in your local instance first, but also the location they pull from each time you open SSMS, or it will always keep adding the default templates (and their folders) whenever you open SSMS.
If you have already opened your Template Explorer, edit one of the files in there (Right Click > Edit) to open it. On the instance that opened, right click on its tab and select Open Containing Folder.
Close SSMS and then delete all but your custom templates from the location that opened. Make a backup of your custom templates somewhere else on your PC, just to be safe.
DO NOT OPEN SSMS YET!! Doing so will rebuild the core templates in your SSMS instance.
Open the following folder path: C:\Program Files (x86)\Micorost SQL Server\120\Tools\Binn\ManagementStudio\SqlWorkbenchProjectItems\Sql
That is where the default templates reside. What I do is create a new folder called "__SQLDefault", then move everything except Sql.vsdir and SQLFile.sql to the __SQLDefault folder (Or whatever you called it). This is in case I ever want to reference any of the core templates...they are still there just in a separate, single folder. If you don't want any of the core templates to be preserved, the other option would just be to delete everything (except Sql.vsdir and SQLFile.sql) instead of putting them in a folder.
Once the files are moved or deleted, now open SSMS and your template explorer should just have the _SQLDefault folder in it (or not if you deleted everything), along with your custom templates that you didn't delete earlier. If your custom ones are gone, just add them back from your backup.

Try changing the Import and Export Settings.

What helped me was editing the registry and Value for DefaultFileOpenLocation
HKEY_USERS\S-1-5-21-1428394981-1396028598-1721912238-1000\Software\Microsoft\SQL Server Management Studio\18.0_IsoShell

Related

What are the project settings in SSRS deployment?

I have successfully created my first SSRS project in Visual Studio. The deployment process requires setting up the TargetServerURL and the TargetServer Version. These are the only two items that I know are correct. The tutorial I have been watching does not go into the other items and does not clarify what they are and what they are used for. What are the following items referring to?
TargetDatasetFolder
TargetDataSourceFolder
TargetReportFolder
TargetReportPartFolder
The default settings for OverwriteDatasets and OverwriteDataSources was False and this is probably why my deployment attemtp threw a nondescript error. So, now, perhaps if I try again, my deployment will create these folders on the server by force, but I owuld rather not do this because the database manager has already given me the names of the folders where I should deploy. So, how are these Folders arranged? Please advise.
TargetDataSourceFolder: The name of the folder in which to store the published shared data sources. If you do not specify a folder, the data source is published to the same folder as the report. If the folder does not exist on the report server, Report Designer creates the folder when the reports are published.
TargetDataSetFolder: the same but for your shared data set you want to publish.
TargetReportFolder: The name of the folder in which to store the published reports. By default, this is the name of the report project. If the folder does not exist on the report server, Report Designer creates the folder when the reports are published.
You can write a path (finance/dept1/...) in this case, you'll deploy your report (or datasets or datasources) following this path.
Here is an exemple by default from microsoft:
About 'overwrite dataset' and 'overwrite datasource' (it's about 'shared dataset' and 'shared datasource') it depends on the architecture you chose (or if you have already something created) on the server.
I think the best way is to let them as False. If they don't exist, the deployment will create them. If they exist, you'll just get a warning (if I remember) and the report you'll be deploying should link your report to those dataset and datasource already created. Futhermore, probably you have other reports linked to those shared datasource/dataset and if you overwrite them, you'll probably raise some issues when you'll run those other reports. You have to put 'True' when you want to modify the dataset/datasource

Where is SQLQuery1.sql saved?

Whenever I open up SSMS (SQL Server 2012), I get all of the scripts that I had open in my previous session. This includes both saved queries and any unsaved queries, which are listed as SQLQuery1.sql, SQLQuery2.sql, etc.
I can't seem to find where these "unsaved" queries are being saved. I've checked Documents\SQL Server Management Studio\Backup Files\ (and every other directory in that vicinity). I've also checked the C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ directory and subdirectories (as best I could). Finally, I did a complete search on my computer for the filename SQLQuery1.sql and it turned up nothing (not that I trust the Windows search function in file explorer).
In case it changes things at all, I also have installed the Redgate SQL Prompt add-on for SSMS.
Any other suggestions?
Thanks!
It's very simple :)
Create new query, then right click on the tab and then choose Open containing folder option.
For example, I got C:\Users\PKuderov\AppData\Local\Temp folder and my SQLQuery4.sql is named ~vs3C67.sql.
So #BenjaminSmith is right but these files have unique temporary names. Until you explicitly save them where you want. It seems they survive ssms reload and you can further filter them by .sql extension and Date Modified.
How about the TEMP folder? Try searching for %TEMP% from your start menu and searching in there.
I got my saved query in the following way.
I made another query and selected to save it.
It popped out the save as dialogue box from where I got all the things which I required.
I copied the file path which was "C:\Users\Shafiq Ur Rehman\Documents\SQL Server Management Studio"

Open Alternate Extension in 'Single Instance' of SQL Server Management Studio

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.

Deploy Visual Studio 2010 Database Project

I have a Visual Studio 2010 Database project, from which I want to generate a script
that simply puts up this database to another machine. The problem is that i can't find a
solution for this.
As I started the project, I imported the shema from a database on my development pc.
The Schema Objects were generated and all tables and scripts where under 'Schema Objects -> Schemas -> dbo'. Over the time, some things changed, some where added. And by using right-click -> deploy,
the changes were made to my local database successfully.
But now I want to deploy to another machine. The problem is, that in the release folder of the project, there is only a xml dbschema file containing all tables and scripts that i can't import
with sql management studio (or i just can't find out how) and the a deployment script which is nothing more than some checks followed by the pre- and post- deployment script, but without any tables or scripts in it.
So please, how do i export the database from Visual Studio, so i can easily put it up on another machine?
Marks--
You likely have already resolved this, but I thought I should answer your questions for the benefit of others.
Yes, you can deploy from Visual Studio to different machines. You can also do it from the command line, using VSDBCMD. And you can create a WIX project to give a wizard for others to install it with.
If you can connect to the target database from your dev PC, you can deploy to it. To do this:
Select another Configuration from the Solution Configuration drop down. Normally, the Project will come with "Debug" and "Release" baked in. You can add another configuration to allow you to deploy to various targets by clicking "Configuration Manager."
Right-click your Project and select 'Properties', or simply double-click Properties under the project.
Click the Deploy tab. Notice that the Configuration: drop-down shows the same selected configuration as "active."
Change the Deploy Action to "Create a deployment script (.sql) and deploy to the database."
Next to Target Connection String, click "Edit" and use the dialog to create your deployment connection to the target database.
Fill in the Target database name, if different.
For each Deployment Configuration (e.g., Debug, Release, etc.), you will probably want a separate Deployment configuration file. If you click "New," you can create one for the current configuration. The new file will open, and you can check and uncheck important things about the deployment.
Note: If you check Always re-create the database, the script will DROP and CREATE your database. You will lose all your data on the target! Be careful what you select here. Most people leave that unchecked for a Production target. I check it for Development or Local because I want a fresh copy there.
Save your changes to the file and to Properties.
To deploy to the target, be sure to select the correct Configuration. Click Build/Deploy [My Database Name]. You probably should experiment with this so you are familiar with how it works before trying it on a live environment.
Good practices: build a similar environment to production ("Staging") and deploy there first, to test the deployment, and always back up the database before deploying, in case something goes wrong.
For more info, please see:
Working with Database Projects
Walkthrough: Put an Existing Database Schema Under Version Control
Visual Studio 2010 SQL Server Database Projects
Is it's possible to point your Visual Studio to your new target database? 1. Properties of your Database project, Deploy tab, set the fields in Target Database Settings.
Now when you generate a deploy script, the resulting SQL file will be the various CREATe / ALTER / DROP etc that will align the target database with your schema.
You could always create an empty database and then do a schema compare in Visual Studio between your database project and the new empty database. You can amend the generated schema update script to also create the database (since the script will be to update an existing empty database)

How does the ClickOnce installer handle updates when a compact database is involved?

I have a simple WPF application that uses ClickOnce to handle installing. Within this application is a compact database. Through testing I have found that when I publish a new build this database will get overwritten, which is not what I want. Is there anyway I can have fine grained control over what files are updated? I assume ClickOnce is simply checking the hash of the database file, deciding that it has changed and pulling the update.
As a workaround I have since removed the database from the files that are included with the published application so the original remains on the client machine after an update, untouched.
Not a great solution I know
Thanks,
ClickOnce deployments segregate the Application Files into "Include" or "Data file". You can specify what each file is in visual Studio by going to the project Properties page, Publish tab, then clicking the "Application Files..." button. You can then set your .sdf file to "Data File" under the Publish Status column.
Data Files that are downloaded with a ClickOnce application are then placed in a separate directory for each new version.
The idea is that on the first run of the new application version, you go retrieve all the user's private data from their old-version data files and incorporate that data into the new data files which have just been downloaded with your new version.
I think you'll find the information you need at Accessing Local and Remote Data in ClickOnce Applications. Specifically, look at the sections "ClickOnce Data Directory" and "Data Directory and Application Versions."
To access a SQL Server CE database located in your Data directory, use a connection string similar to the following:
<add
name="MyApplication.Properties.Settings.LocalCacheConnectionString"
connectionString="Data Source=|DataDirectory|\LocalCache.sdf"
providerName="Microsoft.SqlServerCe.Client.3.5" />
The "|DataDirectory|" is a special syntax supported by SQL CE and SQL Express and resolves at runtime to the proper directory.
If you so much as open that SQLCE database included in your project, it will change the time stamp on the database, and ClickOnce will deploy it and put the old version under the \pre subfolder.
You might want to consider this method for handling this. Then if you accidentally deploy a new version of the database and don't realize it, you're not hosed. If you intentionally make changes, you can change the database structure of your current database with SQL queries, and pull data from the new copy deployed to the Data Directory (that you're otherwise ignoring) when you need to.
RobinDotNet

Resources