The title may be a bit misleading, so let me clarify: I don't want to know how to rename a connection string or db name. What I'm trying to find out is how would I create a friendly label for my database connections in SQL Management Studio?
e.g. I have the following connections:
I want to rename them to something else, e.g. "dev server", "PreProd", "Live", or whatever the case may be. I thought I could easily do this in SSMS, but apparently I can't.
I'm always worried that I may inadvertently make a change on the wrong server and having a nice friendly name will go a long way in preventing it.
I've struggled for years with SSMS database connections that don't have friendly names but are stuck with an IP address or a server/database name. You'd think MS would have provided ways for users to manage these by now, but no.
Something you might consider is using registered servers. SSMS 17 (I don't know about earlier versions) has these and I find them easier to use because you name them whatever you want.
Invoke View/Registered servers to show that pane, then expand the Database Engine node. Right-click the Local Server Groups node and then New Server Registration. Fill out the fields putting whatever you want for a name in the Registered server name box, and test the connection. Once it works, click the save button and you're done. Double-clicking the new registered server connection connects you to the database and opens up the object explorer.
I also switched my startup options (Tools/Options.../Environment/Startup) "At startup" choice to "Open empty environment". This brings up the IDE without prompting me to immediately connect to a database.
Right, so anyway what you have to do is the following
Get the name of the server the IP address points to. You can do this via the command prompt using nsLookup [ipaddress]
use the name instead of the IP address
Alternatively, if you want to control what the actual displayed name is, you could add an entry for each of the IP addresses in your HOSTS file:
Run any text editor as administrator
browse to c:\windows\system32\drivers\etc (etc is a hidden directory) and open the HOSTS file
for each IP address, add a record like such: 1.2.3.4 MyFancyServerName
You can now use MyFancyServerName instead of the IP Address 1.2.3.4.
Adding on to James Barnard's answer.
With SSMS 18.7.1 (and maybe earlier versions) you can actually right click the connection in your Object Explorer and select the Register... option.
This way you don't have to retype your connection details in the Registered Servers window.
SMSS 18.7 server registration steps
Related
At work we are trying to upgrade infrastructure and finally separate app servers and database servers. We would like to migrate our current SQL server DBs to a new database server, but we have many Excel spreadsheets around the office that have database connections and data sources that link to our current db server.
Finding all of those references would be a fairly monumental task. Is there any way to re-route all of these data sources without having to find and update each Excel file that is out there? We're not even sure that all of these use consistent drivers, some may be ODBC, a lot are definitely OLE, some may even use ADO.Net through Excel Macros.
Does anybody out there have experience with a situation like this? Any help is greatly appreciated.
Assuming the connection to the SQL Server in the excel spreadsheets made by DNS name and not IP, then the following procedure will do the work:
Setup the new server with a new host name, a new DNS record , like there's a standard new installation.
Move your data & configuration to the new server. remember to move logins and make sure they mapped correctly.
Change the name of the old server. Make sure the old name is not referenced by the DNS anymore.
Add new DNS record (A record) to your DNS server, referencing to the IP of the new server. (BTW, you can also use WINS/SQL Alias, and not the DNS server way)
Now, the old name is referenced to the new server IP. BUT, connections won't work in AD environment because of the Kerberos protocol. to make it work, assuming the server's new name is newname.ADDomain.com, and the service account of SQL Server is ADDomain\sqlsvc, run the following command on the SQL server: SetSPN -S MSSQLSVC/newname.ADDomain.com:1433 ADDomain\sqlsvc. if you're not in domain environment or not using windows authenticaiton you can skip this step.
After you done, clients will be able to connect the new server with the old name. I suggest that before doing this procedure you'll make sure you know how to do it and how to roll-back in case it's needed (which means, making sure you know how to get the old server up and running with the old name).
If you want to be on the safe side, and ready for future changes, you should consider making a little change: instead of using the old name as an alias to the new server, set up AlwaysOn cluster, and use this old name as the name of the listener, and not the name of the new DB server itself.
this way, future moves will be easier, as the clients will always use the listener name to connect and AlwaysOn will route them to the active server.
Hope this helps.
I need to convert a named instance of SQL server 2005, to a default instance.
Is there a way to do this without a reinstall?
The problem is, 2 out of 6 of the developers, installed with a named instance. So its becoming a pain changing connection strings for the other 4 of us. I am looking for the path of least resistance to getting these 2 back on to our teams standard setup.
Each has expressed that this is going to be, too much trouble and that it will take away from their development time. I assumed that it would take some time to resolve, in the best interest of all involved, I tried combing through configuration apps installed and didn't see anything, so I figured someone with more knowledge of the inner workings would be here.
I also wanted to convert a named instance to default - my reason was to access it with just the machine name from various applications.
If you want to access a named instance from any connection string without using the instance name, and using only the server name and/or IP address, then you can do the following:
Open SQL Server Configuration Manager
Click SQL Server Network Configuration
Click Protocols for INSTANCENAME you want to make available (i.e. SQLExpress)
Right-click TCP/IP and click Enabled
Right-click TCP/IP and go to Properties
Go to the IP Addresses tab
Scroll down to the IPAll section
Clear the field TCP Dynamic Ports (i.e. empty/blank)
Set TCP Port to 1433
Click Ok
Go to SQL Server Services
Right-click your SQL Server (INSTANCENAME) and click Restart
This will make the named instance listen on the default port. Note : You can have only one instance configured like this - no two instances can have same port on the IP All section unless the instance is a failover cluster.
As far as I know, no. One reason is the folder structure on the hard drive; they will have a name like MSSQL10.[instancename]
This is why a lot of companies store their applications' connection strings at the machine level instead of the application level.
Just take the connection string out of the source code entirely. Then have everyone put their connection string in their machine.config.
This has the added benefit of avoiding unnecessary app-specific environment logic, i.e. when you copy your application to the staging server, the staging server already "knows" what database to use.
The only way to change the instance name is to re-install - uninstall and install as default instance.
A lot of times I'll use client alias to point an application at a different sql server than the ones it's connection string is for, esp. handy when working on DTS or an application with a hard coded connection string. Have everybody use a commonly named alias, use the alias in the connection string and point the alias’s on each dev box to the to the different instances. That way you won't have to worry about if the server is the default instance or not.
You shouldn't ever really need to do this. Most software that claims to require the default instance (like Great Plains or Dynamics) doesn't actually.
If you repost with your situation (installed X, then Y, but need to accomplish Z) I bet you'll get some good workarounds.
I think you can migrate your data from Sql Server without having default instance installed. You can just specify the port number of your Sql Server instance in Oracle Sql Developer and you can connect just using the server name, not using the server name and the instance.
Like this:
connect to "MYSERVER, 1433"
I am a beginner with SQL so I struggle with the MSDN description for creating a linked server in Management Studio.
I whant to link a SQL Server into another to use everything from ServerB on ServerA to e.g. provide one location other systems can connect to.
Both servers are in the same domain and both server have several databases inside.
When I start creating a linked server on ServerA in the general tap I select a name for the linked server and select SQL Server as Server type.
But I struggle on the Security tap. I have on both servers sa privilege so what is to set here?
Or which role should I take/crate for this connection?
My plan is to create views in a certain DB on ServerA with has also content of ServerB inside.
This views will be conusumed from an certain AD service user.
I already added this service user to the security on ServerA where the views are stored.
Do I also have to add this user somewhere on the linked ServerB?
I would recommend that you use Windows Authentication. Activate Security Delegation.
In the Security tab, choose "Add". Select your Windows user and check "Impersonate".
As a quick and dirty solution, you can choose "Be made using this security context" from the options list and enter a SQL Login which is valid on the remote server. Since quick and dirty solutions tend to last, i would strongly recommend to spend some time on impersonation.
In Server Objects => right click New Linked Server
2. The “New Linked Server” Dialog appears. (see below).
3. For “Server Type” make sure “Other Data Source” is selected. (The
SQL Server option will force you to specify the literal SQL Server
Name)
Type in a friendly name that describes your linked server (without spaces). – Select “Microsoft OLE DB Provider for SQL Server”
Product Name – type: SQLSERVER (with no spaces)
Datasource – type the actual server name, and instance name using this convention: SERVERNAMEINSTANCENAME
ProviderString – Blank
Catalog – Optional (If entered use the default database you will be using)
Prior to exiting, continue to the next section (defining security)
Click OK, and the new linked server is created
The easiest way would be to specify to make the connection using the current context, i.e. the user loging on to ServerA:
EXEC master.dbo.sp_addlinkedserver #server = N'ServerB', #srvproduct=N'SQL Server'
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'ServerB',#useself=N'True',#locallogin=NULL,#rmtuser=NULL,#rmtpassword=NULL
This however assumes that users accessing the linked server connection have the correct privileges on ServerB (part 2 of your question) - otherwise you'd need to use impersonation as described by Martin K.
Oftentimes I need to troubleshoot a workbook that another person at my company has created and published to our server. To troubleshoot, I need to see their connection details, specifically their Custom SQL, to understand what data they are using in their extract.
Is there any way to view this connection info (specifically their SQL code) when viewing the published workbook on the server (web) version?
I am an admin and I am able to download their workbook to my desktop version of tableau, then open it, then reconnect to the data, then look through the data connections they created, to see their SQL. But it's a really cumbersome process.
All I'm looking to do is, when looking at a published workbook, see the data connection details so that I can see the Custom SQL, without going through the process of downloading I described above.
You can get some details on the SQL statement by creating a performance recording.
From the Tableau Server Admin Guide:
Enable Performance Recordings:
Choose the Admin button in Tableau Server.
Choose Site.
Select a site.
Choose Edit.
In the Edit Site dialog box, select Allow Performance Recording.
Choose OK.
You start performance recording for a specific view by adding ?:record_performance=yes to
the url. For example:
http://server.site.com/views/Variety/BaseballStatistics?:record_performance=yes
Now, notice a new link at the top of your view called "Show Performance Recording".
Click this to open the generated performance workbook dashboard. Click on the bar chart and observe the SQL appear at the bottom of the view. Note, the SQL text will truncate after about 250 characters.
The admin guide suggests viewing the "Tableau Log" to find the full SQL statement.. I have looked at all the server side logs in C:\ProgramData\Tableau\Tableau Server\data\tabsvc\logs but cannot locate the SQL. (please reply if you know where to find this?)
You can also run a database trace to see the SQL that the database sees. For example, for MS SQL Server, run the Profiler tool, setup a default trace, and filter on "Application Name" = "Tableau Protocol Server 8.0" or similar.
I have version 8.1 and this is how I got around this problem. Tableau shows a 'Custom SQL Warning' when you open a workbook that contains the custom SQL. You can copy all the text in this message by simply Ctrl + C as this is any other Windows warning message. And then paste it your editor of choice to analyze it.
I do not know if this works on earlier versions.
I thought you could do this easily, and originally answered that you could, but I didn't pay close attention to your question. You can change some things about data connections without editing the workbook, including the ip address or name of the database server, but there doesn't appear to be a simple way to access custom sql without downloading the workbook.
Go to the Administrator page and select Data Connections.
You can enter some search criteria to filter the list of data connections shown (or not).
Find the workbook in question by scanning the second column -- you can sort the column if that helps.
Then select the corresponding data connection in the 4th column to see the details of the connection.
If it makes sense for the connection, you can also modify the connection directly at the server. This is really useful if you, say, need to move your enterprise database to a new IP address or change a database password, without downloading, modifying and republishing alot of workbooks.
An even better practice is to start using shared data connections hosted on Tableau server instead of having each workbook have its own local copy of connection and related info.
When I click on the "Databases" node in "Object Explorer" it just keeps on "Loading items" until at some point it just hangs.
This happens only when connecting to a remote server, not when accessing a database on my PC.
It also doesn't happen with any other node.
The guys at the web-hosting company didn't have any trouble with it. (But they're running 2008, and so is the SQL server there)
I reinstalled the whole SQL server etc. but to no avail.
What might be the problem?
I experienced this same problem: when accessing a remote server with the Object Explorer, SSMS would hang indefinitely. The Windows System Event Log would show DCOM error 10009 ("DCOM was unable to communicate with the computer MACHINE_NAME using any of the configured protocols.").
The solution was to clear the MRU history and other settings from my profile. To do that:
Close any open instances of SSMS 2012
In Explorer, open "%AppData%\Microsoft\SQL Server Management Studio"
Rename the "11.0" folder to something else, like "11.0.old"
Open SSMS 2012
You'll see that your MRU list has been cleared. You should then be able to re-enter your credentials and use SSMS as normal.
If everything works, you can delete the renamed folder. Otherwise, delete the new "11.0" folder that was created and rename the original one back to "11.0".
I have no idea whether it's actually the MRU list that's causing this problem or if it's some other profile data.
We were able to discover that SSMS is trying to make a DCOM connection over port 135 to the SQL Server (perhaps for SSIS, T-SQL Debugging, or something else). Our firewall was configured to block port 135. By opening the port in the firewall we were able to use SSMS (hence the reason it worked against local databases but not remote ones). Unfortunately, an open port 135 is an invitation for a lot of attacks, so that wasn't a practical solution for us.
Turn Auto-Close off on all the databases. Worked like a charm to me!
Every time you expand or refresh the database list, server has to awake the databases causing the hang.
Just run this to find all the databases that have auto-close on
SELECT name, is_auto_close_on
FROM master.sys.databases AS dtb
WHERE is_auto_close_on = 1
ORDER BY name
Credits to http://social.msdn.microsoft.com/Forums/sqlserver/en-US/99bbcb47-d4b5-4ec0-9e91-b1a23a655844/ssms-2012-extremely-slow-expanding-databases?forum=sqltools
To turn-off this setting for a database - Right click on database instance in object explorer -> Click properties -> Click "Options" in left navigation pane in database properties window -> Change the value of Auto Close property to "False" in right pane as shown in the snapshot below:
Assuming you have access to only one database at the hosting company (which is almost always the case, at least with a certain username/password), you can avoid the need to use the dropdown at all by setting your registered server to default to the database you're supposed to access:
(It may take longer here, too, but this will be one-time. You can also type it instead of waiting for the list to populate.)
This way, even if the login the host created for you routes you to tempdb or something by default, Management Studio will still put you in the context of your database.
I see now that you are talking about the Object Explorer node, not the "Use database" dropdown that I somehow interpreted incorrectly. An exercise to try might be to highlight the databases node (don't expand it) and click on F7 (Object Explorer Details). If this loads for you then it can be an alternative to navigate through the hierarchy and, as a bonus, you can show lots of entity attributes here and also multi-select, two things you have no control over in Object Explorer.
If that doesn't help, then your host should be helping you better than they appear to be. If SSMS 2012 is supported then they should be able to test this in SSMS 2012 and confirm or deny that they can reproduce it. If it is not supported then I think your recourse is to install SSMS 2008 as well (they can co-exist) and use it for managing this specific server.
Of course, just about anything that you can do in Object Explorer (and plenty of things you can't), you can do by using the catalog views and/or DMVs. So before you determine what to do, you may want to review (or share with us) exactly what you are using Object Explorer for - if there is a way to do it without Object Explorer, you might like the workaround better than having two versions of the tool (since the improvements in 2012 SSMS have absolutely nothing to do with Object Explorer).
In my case deleting the profile folder worked exactly once. The next time I opened SSMS 2012 it would freeze again when connecting to a server. SP1 didn't fix this either.
That was until I found the following simple workaround described on a ticket by Ben Amada over at connect.microsoft.com: Always close the Object Explorer Details before closing SSMS 2012.
So the complete workaround for me is this:
Follow Jaecen's answer, but close SSMS 2012 again after it created a clean profile folder
Apply Hoodlum's recommendation and copy SqlStudio.bin from the old profile folder to the new one (the old profile folder can be deleted afterwards)
Everytime before closing SSMS 2012 make sure the Object Explorer Details window is closed
The first two steps are required only once, or if the Object Explorer Details window was left open accidentally.
Edit
I just noticed that closing the Object Explorer Details window is also required when (re-)connecting to an SQL server in the same SSMS session. So basically whenever connecting to a server the Object Explorer Details windows has to be closed.
I spent over a month with Microsoft SQL Support troubleshooting this. It has been submitted as a bug.
I have both SQL 2012 SSMS and VS 2012 installed on Win 7 (64).
Deleting the profile folder never worked for any reasonable length of time.
The workaround we found was to ensure that my SSMS profile defaulted to the Master database when connecting. It appeared to have something to do with the fact that I'm connecting with Windows Authentication and I belong to more than one AD group that have SQL permissions assigned AND I don't have SQL specific permissions set up on my AD account.
I am connecting to several remote servers rangig from 2000 to 2012.
SMSS on local PC is SQL Server 2012,SMSS is 11.0.2100.60
SSMS freezes several times a day.When this occurs, I go via RDP to the
local server / SMSS / Activity Monitor and kill the processes from my PC with Database Name = master, one at a time, until SMSS on my PC unfreezes.
This always works, however, a cure for the disease raher than the symptoms would be highly welcome.
Have some SQL Servers from 2000 to 2012,
access then through SMSS from my desktop.
Problem occurs with varying frequency, looks like this: when I collapse a server in object explorer, SMSS freezes.
looking in activity monitor on the server in question, i find a process in master db with host = my desktop executing the following query
SELECT dtb.name AS [Name] FROM master.dbo.sysdatabases AS dtb ORDER BY [Name] ASC SMSS
killing the process frees SMSS.
Here is what worked for me
Open SSMS
click on connect to object explorer button
in the connect to server dialog box expand options >>
click reset all
Done!
I've test approximately all above answers but my SSMS got stuck in expanding the database list. I found the problem finally. The problem was because of a database that I restored it but It did restore correctly at the end. Then When I expanded the database list it was sticking.
I run a the query
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM master.sys.databases AS dtb
Then the result took too long and at the end timed out but When I filter the stuck database I got result.
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM
master.sys.databases AS dtb
Where name <> 'StuckDB' ORDER BY [Name] ASC
At the end I decided to detach StuckDB to solve my problem.
I have now applied SQL 2012 Service Pack 1 (through Windows Update) and it seems to work fine now, though it does take a very long time to load.
"Open SSMS click on connect to object explorer button in the connect to server dialog box expand options >> click reset all" - it works
I solved this problem by changing my default database back to master.
Go to database properties at SSMS and change compatibility to 2012. Then check.