Machine 1
Windows Server 2008
SQL Server 2008
The database. Contains all the information our sites use.
Machine 2
Windows Server 2012
IIS 8
The webserver. Uses IIS to host two sites:
Production site: (default) Has the most up-to-date UI and features
Backup site: Older UI, but still using the latest data from Machine 1
Here's how it works:
User goes to one of the sites hosted on Machine 2 and enters their company information
Machine 1 is queried for that company's connection string.
The site uses the connection string to connect to the correct database on Machine 1.
The problem is that about 1/3 of the connection strings use the network name (e.g. "Data Source='Machine1';") while the other 2/3 use the IP address (e.g. "Data Source=192.168.1.200;"). When connecting via the Production site, a timeout occurs if uses a connection string with a network name. However if the same user, using the same credentials, logs in to the Backup site, everything works fine regardless of which 'Data Source' is used.
I created a simple Powershell script to test the connection from Machine 2; network names and ip addresses both work, which makes me suspect it is an IIS or web.config issue. I've gone through both extensively, and these are the only differences I've noted:
Different Application Pools in IIS: However when I ran "Get-CimInstance Win32_Process" it showed both instances of w3wp.exe had been started with the same command and arguments (with the exception of different pipes)
Slightly different web.config. The Backup site has an entirely self-contained web.config, while the Production on stores its connection strings is a separate file.
Been banging my head against this for several days. Very limited in the steps I can take considering this a production website and
Database. Any advice is appreciated.
Try putting the network-library in the connection string to force tcp.
see connectionstrings.com/define-sql-server-network-protocol
;Network Library=DBMSSOCN;
PS
Yep. Been there, done that. 4 days of "on site" client visit.......and it was the protocol.. Thus how I learned to force it via the connection string. You can also try this:
Create a (temporary) System DSN (ODBC in Control Panel) with a weird name like "peanutbutter". There is a client connection button in there somewhere. Force it to tcp. Then search your registry for peanut butter and find out how the network library gets stored.
A picture is worth a thousand words. See left side of image below. (a random image from the old interweb)
Related
I am attempting to set up a communication between Labview and Microsoft SQL Server, on two separate devices, in order to send and receive information about the database from both labview to SQL Server and SQL Server to labview. However, when I reach the "Data Link Properties" menu, I get the same "unable to log in" error upon attempting to log into the server. The server name comes up, however, an error occurs once I move on to select the database on that server. Is there any solution or tutorial to this problem that can allow me to successfully communicate back and forth from labview and smss on separate devices?
I've opened up various ports to allow a connection, even disabled the firewalls on both devices. The devices are connected via an Ethernet cable and I AM able to ping the devices to each other. However, in regards to being unable to log into the server in ssms, I have created new users, adjusted the login properties, tried changing permissions, but anything I try doesn't seem to solve my issue.
Can't really help much without seeing the error or some of the code of what you are trying to do.
That being said, if you go to the menu and select Help>Find Examples... and search for database, you should see a bunch of different things related to database connections. You may find the Database Connection.vi one helpful.
More info on the Database Connectivity Toolkit in LabVIEW can be found here
I see there can be one of the 2 issues
1) Inbound/Outbound port rules not set, Remote connection to server is not allowed.
2) If the server has multiple instances then you need to provide full host name of the instance you are trying to connect.
*Please refer to the below link to configure firewall rules.
https://learn.microsoft.com/en-us/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-2017
Scenario:
Single SQL Server with 2 instances -> .\test & .\live
Single IIS server with 2 websites -> test & live
test website's web.config points to the .\test SQL server instance, live website points to .\live. The SQL Server instances are identical in every way, i.e. DB names, SQL username / password, etc. The only way they differ is by the ports they listen on.
We have the following code deployed to the test website:
_logger.Debug("connection string: " + _context.Database.Connection.ConnectionString);
_context.Database.ExecuteSqlCommand("stored_procedure #param");
When we check the logfile after this code has executed, it shows that the connection string is pointing to the .\test instance, as expected. But a SQL Profiler trace shows that stored_procedure is being executed against the .\live instance.
We can't figure out why or how this is happening, any help?
The missing piece of the puzzle was the ports. As per the comments on this answer, MSSQL ports and instances are the same thing... and port overrides instance name if specified.
Our connection strings looked like the following:
test: Data Source=server\test,7777;Initial Catalog=ourdb;Persist Security Info=True;User ID=user;Password=pass
live: Data Source=server\live,7777;Initial Catalog=ourdb;Persist Security Info=True;User ID=user;Password=pass
So although they were pointing to different instances, the same port overrode that and forced them both to effectively point at whatever was running on port 7777 - i.e. the .\live instance, hence the anomalous behavior we experienced.
I've recently moved a classic ASP site from a single-server IIS6 (Window Server 2003) and SQL Server 2005 setup, to a Hyper-V setup running Windows Server 2012 on the host and two VMs (single machine).
Here is a diagram of the current setup:
My problem is that I am getting the following error intermittently:
Named Pipes Provider: Could not open a connection to SQL Server [53].
I've been told and was able to prove that the web-to-DB traffic never uses the physical NIC, so that should rule out any issues w/ the NIC or its drivers/configuration.
I've also made sure that there are no IP conflicts (the host and VM IPs are all different).
The only pattern I can detect is that it seems more likely to happen during peak periods. The odd thing is it can go 7 days without an error, and then on a single day, the error will happen on 50-100 requests, often within the same 30 seconds, or in groups of 30-second intervals.
I've been trying to figure this out for weeks -- since migrating to the new server over 3 weeks ago. If no one here can help, my last resort is to open a ticket with Microsoft. However, I'm not optimistic they will be able to help as I'm not able to reproduce it.
As a last resort, I'm considering moving them back to a single instance, which I'm trying my best to avoid.
Update:
Here is the connection string I'm using:
Provider=SQLNCLI11;Server=[my DB VM IP address];Integrated Security=SSPI;"
I'm trying to set up mirroring between two sql 2008 databases on different servers in my internal network, as a test run before doing the same thing with two live servers in different locations.
When I actually try and switch the mirroring on the target DB (with
ALTER DATABASE testdb SET PARTNER = N'TCP://myNetworkAddress:5022') I'm getting an error telling me that the server network address can not be reached or does not exist. A little research suggests this is a fairly unhelpful message that pops up due to a number of possible causes, some of which are not directly related to the server existing or otherwise.
So far I've checked and tried the following to solve this problem:
On the target server, I've verified that in SQL Configuration Manager that "Protocols for SQLEXPRESS" (my local installation is labelled SQLEXPRESS for some reason, even though querying SERVERPROPERTY('Edition') reveals that it's 64-bit Enterprise), and Client Protocols for SQL Native Client 10 all have TCP/IP enabled
I'm using a utility program called CurrPorts to verify that there is a TCP/IP port with the same number specified by the mirroring setup (5022) is open and listening on my machine. Netstat verifies that both machines are listening on this port.
I've run SELECT type_desc, port FROM sys.tcp_endpoints; and
SELECT state_desc, role FROM sys.database_mirroring_endpoints to ensure that everything is set up as it should be. The only thing that confused me was the "role" returns 1 .. not entirely sure what that means.
I've tried to prepare the DB correctly. I've taken backups of the database and the log file from the master DB and restored them on the target database with NORESTORE. I've tried turning mirroring on both while leaving them in the NORESTORE state and running an empty RESTORE ... neither seems to make much difference. Just as a test I also tried to mirror an inactive, nearly empty database that I created but that didn't work either.
I've verified that neither server is behind a firewall (they're both on the same network, although on different machines)
I've no idea where to turn next. I've seen these two troubleshooting help pages:
http://msdn.microsoft.com/en-us/library/ms189127.aspx
http://msdn.microsoft.com/en-us/library/aa337361.aspx
And as far as I can tell I've run through all the points to no avail.
One other thing I'm unsure of is the service accounts box in the wizard. For both databases I've been putting in our high-level access account name which should have full admin permissions on the database - I assumed this was the right thing to do.
I'm not sure where to turn next to try and troubleshoot this problem. Suggestions gratefully received.
Cheers,
Matt
I think that SQL Express can only act as a witness server with this SQL feature, you might get better mileage on ServerFault though.
Mike.
Your network settings might be OK. We got quite non-informative error messages in MS SQL - the problem might be an authorization issue and the server still will be saying "network address can not be reached".
By the way, how the authentication is performed? A MSSQL service (on server1) itself must be runned as a valid db user (on server2, and vice versa) in order to make the mirroring work.
Suppose the following:
I have a database set up on database.mywebsite.com, which resolves to IP 111.111.1.1, running from a local DNS server on our network.
I have countless ASP, ASP.NET and WinForms applications that use a connection string utilising database.mywebsite.com as the server name, all running from the internal network.
Then the box running the database dies, and I switch over to a new box with an IP of 222.222.2.2.
So, I update the DNS for database.mywebsite.com to point to 222.222.2.2.
Will all the applications and computers running them have cached the old resolved IP address?
I'm assuming they will have.
Any suggestions along the lines of "don't have your IP change each time you switch box" are not too welcome as I cannot control this aspect of the situation, unfortunately. We are currently using the machine name of the box, which changes every time it dies and all apps etc. have to be updated with the new machine name. It hurts.
Even if the DNS is not cached local to the machine, it will likely be cached somewhere along the DNS chain between the machine and the name servers, at least for a short while. My understanding is this situation would usually be handled with IP takeover where you just make the new machine 111.111.1.1.
Probably a question for serverfault.
You're looking for DNS TTL (Time To Live) I guess.. In my opinion applications may cache the IP for at most the value of the TTL. I'm afraid however that some applications/technologies might actually cache it longer (agian in my opinion completely wrong)
Each machine will cache the ip address.
The length of time it is cached is the TTL (Time To Live). This is a setting on your DNS server, if you set it very low say 5 mins, then you show be up and running fairly quikly. A bit of a hack but it should work.
Yes, the other comments are correct in that what controls this is the DNS TTL set for the hostname database.mywebsite.com.
You'll have to decide what the maximum amount of time you're willing to wait for if you have a failure on your primary address (111.111.1.1) after you make the switch to the secondary address. Lower settings will give you a quicker recovery time, but will also increase the load and bandwidth to your DNS server because clients will have to re-query it to refresh their cache more often.
You can use nslookup using the -d option from your cmd prompt to see what your default TTL times and remaining TTL times are for the DNS server you are querying.
%> nslookup -d google.com
You should assume that they are cashed for two reasons not clearly mentioned before:
1- Many "modern" versions of OS families do DNS caching.
2- Many applications do DNS caching or have poor error/failure detection on live connections and/or opening new connections. This would possibly include your database client.
Also, this is probably not well documented. I did some googling, and found this for MySQL:
http://dev.mysql.com/doc/refman/5.0/en/connector-net-programming-connecting-connection-string.html#connector-net-programming-connecting-errors
It does not clearly explain its behavior in this regard.
I had a similar issue with a web site that disables the application pool recycling features and runs for weeks on end. Sometimes, a clustered SQL Server box would restart and for some reason, my SqlConnection's were not reconnecting. I was getting the error:
A network-related or instance-specific
error occurred while establishing a
connection to SQL Server. The server
was not found or was not accessible.
Verify that the instance name is
correct and that SQL Server is
configured to allow remote
connections. (provider: Named Pipes
Provider, error: 40 - Could not open a
connection to SQL Server)
The server was there - and running - in fact, if I just recycled the app pool, the app would work fine - but I don't like recycling app pools!
The connections that were being held in the connection pool were somehow using old connection information, and that could have been old IP addresses. This is what seems so similar to the poster's question, that it appears to be cached DNS information, because as soon as some sort of a cache is cleared, the app works fine.
This is how I solved it - by forcing all of the connections in the pool to be re-created:
Try
' Example: SqlDependency, but this could also be any SqlConnection.Open call
Dim result As Boolean = SqlClient.SqlDependency.Start(ConnStr)
Catch sqlex As SqlClient.SqlException
SqlClient.SqlConnection.ClearAllPools()
End Try
The code sample is just the boiled-down basics - it should be tweaked for your situation!
The DNS gets cached, but for any server that resolves to the wrong ip address, you can update the HOSTS file of the server and the ip should be updated immediately. This could be a solution if you have a limited amount of servers accessing your database server.