The primary goal is determine whether machine is local or remote by machine name.
I have to complete a list with all well known aliases of localhost.
So here I am:
var localAddressList = new List<string>
{
#"(local)",
// #"(localdb)",
#"(localhost)",
#"localhost",
// #"localhost -4",
// #"localhost -6",
#"127.0.0.1",
#"::1",
#"."
};
But I am not sure about commented aliases.
Do you know another aliases ?
Can anyone share with me where to find this information ?
You can check your DNS Server definitions and your SQL Server Aliases definitions.
SQL Browser will check for SQL Server hostname and aliases.
Inside Sql Server Configuration Manager go to SQL Native Client XX.0 Configuration (XXbit) then Aliases section.
Also any computer with a modified hosts file or another DNS Server could address the server with another name (this does not mean SQL Browser will answer properly though).
Make sure to check the following file it might contain your desires :
C:\WINDOWS\system32\drivers\etc\hosts
Related
I am hoping to get some input on a configuration challenge I am having with a connection string connecting to a named SQL server instance when DNS resolution is not available.
What I have is a third party application that gets a connection string injected into a web.config file via a configuration utility. The configuration uses the server-name\instance-name format to connect to SQL server.
However, the server itself does not have the ability to resolve the name via DNS so it will not work. I can get the database connection working by using the IP address and unfortunately I cannot change the instance name that gets pushed to the web.config file.
I am trying to avoid having this break and need to be manually adjusted any time the configuration gets pushed.
What I am hoping to do is utilize the hosts file to get the connection working properly, but maybe there is another solution.
The database is a named instance, but is using the default port so in my hosts file I am able to add this:
Server-IP Server-Name
and then in my web.config use just the server name server-name in the connection string data source to make a connection.
However, the configuration will always push the data source as server-name\instance-name so I need to somehow get that additional instance name working in my local resolution.
I did try in the hosts file:
Server-Ip Server-Name\Instance-Name
but that did not work. Also server-name\instance-name in the connection string does not work with just the server-name in the hosts file.
As a reference all of the following will work in the connection string without anything in the hosts file:
Server-IP
Server-IP,Port
Server-IP,Port\InstanceName
but the only thing I can get working is server-name only in the hosts file and connection string.
As indicated by AlwaysLearning in the comments, the solution was to allow udp/1434 access for SSRP queries.
We have a Server A and a Server B.
In Server A we have our ERPs made in Access and VBA.
In Server B we have an instance of SQL Server that needs to stay in that server.
Some Access databases need to link to some tables from that SQL Server instance and I don't want the password to be stored in the MSysObjects table, so I cannot manually link the tables checking the save the connection option.
I saved the connection string in a table with password obfuscation. With that connection string I re-link the tables on startup.
The instance is accessed through it's IP, not the name of the instance. If I use the name of the instance it doesn't work.
It works for me but not for other users except one.
The SQL Server instance has been properly configured to allow remote connections, the ports have been opened and rules added to firewall. If it wasn't properly configured it wouldn't work for me and the other user, so I'm pretty confident in that. The same with the connection string and the methods to stablish the connection in Access.
What I've tried:
Installing the SQL Native Client 11.0.
Installing a full SQL Server Express.
Configured the SQL Browser service to star automatically instead of being disabled.
Step 1 did not work for any user. Step 2 did work for one user but not for the rest. Step 3 did not had any effect. For me I had it installed in my machine since forever, so it doesn't apply.
If I try to do the same with a SQL Server instance in our LAN it works for every user, but not when the instance is in a remote server.
Note I have limited knowledge. Maybe I say something that does not make sense.
Ok, a few things:
Installing the SQL Native Client 11.0.
Ok, then you have to re-link the tables - choose the new driver. A refresh of the linked tables is NOT sufficent. And this ALSO means that each work station ALSO now must have native 11 instlled. And if you say decide to link using native 17 (a much newer odbc driver), then AGAIN YOU must install this native driver on each work station. While you can install multiple sql drivers on each workstation, the driver you used to link the tables MUST ALSO be installed and exist on each work station.
Installing a full SQL Server Express.
Why? What would installing a copy of sql server have to do with OTHER sql servers on other machines that you are attempting to connect to? You think installing sql server on a machine effects the sql server running say on amazon.com? So, this move makes no sense at all.
You are attempting to connect to some instance of sql server running on some other computer. Makes no sense nor will it help to install some copy of sql server that you not using, not connecting to, and that has zero to do with this issue.
Configured the SQL Browser service to star automatically instead of being disabled.
Where? The browser service is set to run and startup on the server and SAME machine where sql server is installed and running. So, yes, without question, those two sql servers A, and B most certainly MUST have the sql browser service running. That service is what allows the client computers to connect to that running instance of sql server. In the past, older (previous) versions of sql server would allow a default connection, but now in near all cases, you MUST ensure that the sql browser service is running on that computer that also has the database you are attempting to connect to.
it's worth to note that the instance is accessed through it's IP, not the name of the instance.
No, you likly have this incorrect. There are two part.
The server name - and then the "instance" of sql server running.
While you can swap out (not use) the server name, you STILL WILL NEED to specify the sql server instance.
So, you can use this format:
myservername\SQLEXPRESS
Or, you can replace the server with a IP address, but you STILL NEED the sql server instance. (by default, it is SQLEXPRESS - but you have to check what the instance of sql server database is).
192.168.1.30\SQLEXPRESS
So while you can use IP or server name - it is often more reliable to use the IP address, but that does NOT get you off the hook from having to specify the sql instance you connect to. Again, previous editions of sql server often allowed a "default" instance, and you did not in general have to specify the "instance", but now you do. And to be double clear, when using such a instance, that sql server needs to be running the sql browser service. (in fact, the browser service is what translates the incoming request to the given and correct instance of sql server).
I DON'T want the password to be stored in the MSysObjects table,
You don't have to, and in fact should NOT include the uid/password in your connection string. And in fact ZERO reason exists to do so.
What you do is execute a one time logon, and THEN link the tables without UID/password. This is not only a great idea, but it also means that your uid/password is not included in the connection strings, but also means users can't get at, or even by accident see/get the uid/password.
It also means that say someone where to launch a copy of access, and import the linked tables from this applcation. When they attempt to use the linked tables, they will NOT work.
So, then how do linked tables work without a password? (and this ALSO by the way saves you from having to re-link tables on startup!!!).
The way this works, is you in code execute a one time logon to the server on startup. That means you can either:
Prompt the user for their sql UID/password.
or
Have in code, the uid/password. (or perhaps in a text file y ou read on startup. You can thus hide, or encrypt or whatever for that uid/passwords.
Then in your startup code, you execute a one time logon. Once you done this, then all linked tables will now work - and work without having uid/password.
since you have two servers then you need to execute two logons, one for server A, and one for server B. But, once again, as long as the linked tables exist, then they will work.
Now, there are "longer" articles on how to use this logon idea, and then not have to include, or re-link your tables for the SQL uid/password.
The basic code to execute a logon is like this:
Function TestLogin(strCon As String) As Boolean
On Error GoTo TestError
Dim dbs As DAO.Database
Dim qdf As DAO.QueryDef
Set dbs = CurrentDb()
Set qdf = dbs.CreateQueryDef("")
qdf.connect = strCon
qdf.ReturnsRecords = False
'Any VALID SQL statement that runs on server will work below.
' this does assume user has enough rights to query built in
' system tables
qdf.sql = "SELECT 1 "
qdf.Execute
TestLogin = True
Exit Function
TestError:
TestLogin = False
Exit Function
End Function
Keep in mind, that ONCE you acheived a legal logon, then EVEN addtional logon attempts will return true.
Not usually a big deal, but this means you supply a valid connection to above, and if it logs on and works - then now all your linked tables (without uid/password) will work.
I note the above issue that ONCE you done the logon, then all 2nd or more times running the above will work (even if bad or incorrect!!! - DO NOT forget this tip!!!). (this can confuse the daylights out of a developer, since they execute logon, (or open a table). Then they test above routine with a BAD uid/passwords, and it works!!!
So, you have to EXIT access to clear out the password cache - no other way.
So, keep the above tips in mind.
I want to move a SQL database to a new region. A bit of downtime is okay.
One hard requirement is that the SQL Server name stays the same, are there are several places that the connection string is in use.
With FailOver I believe the server name doesn't change after failing over to the new region.
However once I remove the failover and delete the old SQL Server I expect that this will no longer be that case
Migrate Azure database server/database different region
https://learn.microsoft.com/en-us/azure/azure-sql/database/move-resources-across-regions
The other option, Is to create a SQL Server alias
https://learn.microsoft.com/en-us/azure/azure-sql/database/dns-alias-overview
and slowly migrate all connections to the alias
First you could use Geo-Replication to have the Fail-Over to the New Server
Then the Original server must be deleted
Then using the DNS alias - Azure SQL Database | Microsoft Docs You could refer
to the same name of the original server as the alias and so as to make sure that
the original server name is not retained after the deletion and hence can have
the same name.
The DNS alias acts as a translation layer, allowing your client programme to be redirected to multiple servers. This layer eliminates the hassle of having to locate and edit all of the clients’ connection strings.
In the Azure SQL Database service system, creates a new DNS alias.
Server 1 is referred to by the alias.
Obtain a list of all DNS aliases assigned to server 1. The server name for which
the alias is configured is changed from server 1 to server 2.
Using the name of the alias, remove the DNS alias from server 2.
Limitations:
The updating or removal of a DNS alias can take up to two minutes.
The alias immediately ceases referring client connections to the legacy server,
regardless of any small latency.
DNS lookup: Performing a DNS lookup is currently the only authoritative technique
to determine which server a particular DNS alias corresponds to.
Table auditing is not supported: A DNS alias on a server with table auditing
enabled on a database is not supported. Table auditing is no longer recommended.
Instead Blob Auditing could be used.
We're in the process of switching from Windows Server 2003 to Windows Server 2008, and we've encountered a frustrating problem:
In the old environment, some developers used sql server 2005 and others used sql server 2008. No problems. Our connection strings all pointed to: localhost/sqlserver. Now, on the new Server 2008 environment, Sql Server 2008 is occasionally resolving the "localhost" which immediately causes the thing to throw an exception.
In sys.servers we've changed the entry to point to localhost/sqlserver using:
exec sp_dropserver 'buckaroo-banzai\sqlserver'
exec sp_addserver 'localhost\sqlserver', local
exec sp_serveroption 'localhost\sqlserver', 'data access', TRUE
and the most frequent offending sql statements look like this (I know it's deprecated form) (note: they aren't the only offenders, just the most common ones):
[localhost\sqlserver].[database].[table].exec sp_executesql blahblah; exec sp_another_sp
The error I'm getting from those is:
Server buckaroo-bonzai\sqlserver not found in sys.servers
switching my sys.servers entry back to buckaroo-bonzai\sqlserver gets this error:
Server localhost-bonzai\sqlserver not found in sys.servers
If everything refers to the sql server as buckaroo-bonzai\sqlserver everything works, but for development, this just isn't an option.
For the record, this hasn't happened before on our windows server 2003 environments, just the new server 2008 environments; any ideas?
possible workarounds I've thought of:
remove the app.config and web.config files from version control (yech)
laboriously keep different connection strings in version controlled files (double yech)
version control the files, but somehow have some unified way of referring to an sql server on a local host (localhost maybe? )= )
Actually figure out why sql server 2008 is resolving localhost and stop it dead. (yay!)
Check the hosts file for redirection
Does it work any better if you use "." instead of "localhost", as in ".\sqlserver"? A single period refers to the local machine, but there's obviously no way to do a DNS lookup on it, so I doubt SQL Server would try.
It's not DNS or HOST file: the 4 part object name can't resolve because of no sys.servers entry.
You might be able to workaround with sp_addlinkedserver
EXEC sp_addlinkedserver
'buckaroo-banzai\sqlserver',
N'SQL Server',
#datasrc = 'localhost\sqlserver'
Now, this may fail (I can't test) because the "data_source" in sys.servers would be duplicated with "localhost\sqlserver". However, you can change this to something like "127.0.0.1\sqlserver" or "actualservername\sqlserver" to remove the duplicate.
I'm sure I did this some time ago...
Edit, after comment: The error might be related to Behaviour change in SQL 2008 for loopback linked servers. Sorry, i did't know about this.
sp_addserver is only useful for changing local server name (that is ##servername).
Well, sounds like a DNS issue. Not sure why it would have problems referring to itself as "localhost", but you might want to check your system HOSTS file, to make sure that hasn't been changed somehow.
The order of resolution for a DNS query is as follows:
The host first determines whether the name in question is its own name. It should take its actual name, as well as localhost, to be valid. If this isn't happening, it may not think it is who YOU think it is.
A Hosts file, located on each host, is queried. This file will override any external DNS.
DNS Servers are queried. If it can't find any information locally, it will ask someone, and that answer may not be correct, depending on how your DNS is configured.
As a last result, a host can use NetBIOS to try and find a host. This is bound to cause issues somewhere. Not a good thing to depend on, because often things will seem to just work, but then unexpected behaviour crops up, and it's hard to diagnose.
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"