We have moved our TFS data tier server to another machine. Everything was reconfigured and is working EXCEPT email alerts. Test emails are sent just fine. However, alerts are not happening. When I checked the event viewer, I'm seeing the following error:
ds:OLDSERVERINSTANCE db:Tfs_Configuration errors:-1 exception:System.Data.SqlClient.SqlException (0x80131904): 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: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
So, it appears that the email is still looking at the old database (which has been retired). Where/how can I change this?
In case anyone else runs into this scenario. The TFSJobAgent wasn't smart enough on reboot to recognize the data tier change. Doing the following worked:
1. Stop iis
2. Stop the TFSJobAgent
3. Start the TFSJobAgent
4. Start iis
Related
Our application keeps on crashing once per day (at the start of the workday). Because of what it seems connection with database.
[31merror[39m: [SSL-QTEH-TD] E01000-SYSTEM_ERROR: [IBM][CLI Driver]
SQL30081N A communication error has been detected. Communication
protocol being used: "TCP/IP". Communication API being used:
"SOCKETS". Location where the error was detected: "000.00.00.00".
Communication function detecting the error: "recv". Protocol specific
error code(s): "104", "*", "0". SQLSTATE=08001
I'm unable to determine why this is happening.
You have a communication related SQL Error at the start of each working day. This implies that the network connectivity between your application and the database server was broken overnight, most likely for a scheduled downtime.
This could have been one or more of your app, the server your app runs on, any proxy or firewall servers servers between your app and the database server, the database, the server the database runs on.
Most likely it will be the database, allowing it to run reorgs and make backups. Next likely is a firewall, shutting down to allow maintenance. In any case your app needs to be able to detect the disconnect and recover.
I have 2 servers, a SQL Server 2012 and a SQL Server 2008R2.
Database mail works fine on the 2012 but does not work at all on the 2008R2.
The account and profile settings are the same on the two servers, and on both servers mail sent with the .NET mail interface goes through okay.
I cannot find any differences between the SQL Server instances.
The message I get is:
The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 4 (2016-10-28T14:34:57). Exception Message: Could not connect to mail server. (No connection could be made because the target machine actively refused it **************:25).
SQL Server Agent is disabled on both servers, so that is not a factor.
The machine.config and web.config files are basically the same on both servers.
I have followed all the steps outlined in the msdn information, and yet nothing works yet.
Is there something else I should be looking at on the SQL Server 2008R2 instance?
I found the answer to my question.
It is a McAfee setting on our production server.
The setting on the development server is not the same.
The setting in question blocks port 25.
It is discussed in the following:
http://www.sqlservercentral.com/Forums/Topic956956-146-1.aspx
We have Tableau Desktop & Redshift as datasource. When we are publishing the report to Tableau server (hosted) we are getting following error :
An unexpected error occurred on the server. If you continue to receive this error please contact your Tableau Server Administrator.
TableauException: Could not connect to the server; A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. [58.89.281.166:5439] Unable to connect to the server "abc.redshift.amazonaws.com". Check that the server is running and that you have access privile...
2014-06-17 13:56:20.974 (U6BI2gq#AWoAAB0gowQAAAGi,0,1)
This is likely caused by the Tableau Server not being able to access the Redshift Server you listed. It looks like a time out occurred which indicates that a connection attempt failed.
Since it's hosted, you might not be able to verify the connection directly. If you can log onto the Tableau Server and access Windows, you can attempt to establish a connection to the RedShift server at the command line using a tool like Telnet. You need to make sure that the Tableau Server in question can access the Redshift server (verify firewall and security settings for both the Tableau Server and Redshift instance).
I have an application that can connect to the Principal, but can't connect to the Mirror during a failover.
(Note to moderator: please let me know if this question is more appropriate for serverfault. I posted it here because I found more questions similar to this issue than on serverfault.)
This is the error I receive when my application attempts to connect to the Mirror after a failover:
Named Pipes Provider: Could not open a connection to SQL Server [53].
Cannot open database "MY_DB_NAME" requested by the login. The login failed.
I am familiar with the fact that when initially connected to the Principal, the name of the Mirror server is cached to be used during the failover and that the failover partner I specify in my connection string is only used if the initial connection to the Principal fails.
This clearly describes the problem I'm having:
http://blogs.msdn.com/b/spike/archive/2010/12/15/running-a-database-mirror-setup-with-the-sqlbrowser-service-off-may-produce-unexpected-results.aspx
...but the SQL Browser Service is running and I can't figure out why the name won't resolve when connecting to the mirror.
I'm assuming there is a service that must be running to enable NetBIOS name resolution that is not running, because this is what I see in WireShark consistently without a response from the Mirror:
Source Destination Protocol Length Info
10.200.3.111 10.200.5.255 NBNS 92 Name query NB SQL-02-SVR-<00>
Question 1: What could be causing the problem? ;-)
Question 2: I really don't want to enable NetBIOS (for security reasons) and I'm using IP addresses (no FQDNs) in the mirror configuration and in the connection string. Given the caching behavior of the mirror partner when connecting to the Principal, is there a way to force TCP/IP to be used so the value that is cached is the IP address and not the name? Do I need to run the SQL Server Browser/Computer Browser services?
The configuration:
App Is Delphi XE2 using SDAC 6.5.9 (I don't think this is relevant to the component I'm using because it works in other installations with mirroring and has no issues)
SQL Server 2012 Enterprise installed as a default instance on Principal, Mirror and Witness in a non-domain configuration using certificate authentication.
Windows Server 2008 R2 SP1 64-bit on all machines
Firewalls disabled on Principal, Mirror and Client (where app is running)
TCP/IP and Named Pipes enabled on Principal and Mirror
SQL Server Browser service running on Mirror
Computer Browser service running on Mirror
Mirroring is configured for automatic failover with a witness and works properly (I can fail back and forth between mirror and principal without issue)
SQL Native Client 2012 installed on Client machine
Same app login (with same SID and user rights) exists on both Principal and Mirror
Correct server, failover partner, database name, user name and password verified in my app log
In connection string, principal server is 'tcp:10.200.3.15,1433' and failover partner is 'tcp:10.200.3.16,1433' using the SQL Native client
I can ping both servers from the Client machine
NetBIOS over TCP/IP has been enabled in the adapter under the WINS tab (on the Mirror and Client machines)
I've been able to get the application working with mirroring on several other installations, but this one is baffling me.
I found the problem, which was that the customer had the Principal and Mirror in one VLAN and the Client(s) in another. Although the IP addressing scheme was the same, the policy for communication between the VLANs prevented broadcast messages, which is why the NetBIOS query was failing on the client. A WINS or DNS server will be implemented to resolve this issue.
However, I am still interested in an answer to my Question #2, above.
A little background:
I have a Windows .NET application that is in use by approximately 40 field employees across North America. This program allows the users to enter data while in the field (away form internet access) and then synchronizes to our Sql Server 2005 database at night. A couple days ago, two of my users reported getting the following error when they performed an action that would attempt to connect to our server database (which uses .NET's SqlConnection class).
System.Data.SqlClient.SqlException: 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)
Our field employees are typically operating on a hotel Wi-Fi connection, and at first I thought that they both coincidentally got on an "uncooperative" network the same day. The following day, having moved to different hotels, the problem went away for one of these users, but continued for the other.
Besides providing the error message, the purpose of this background is to point out that
this is the first time this issue has occurred in over a year of using this software, and
the majority of our users aren't having any problem connecting to our server database with the same software.
This makes me hesitate to think that the issue is at the server (most forums and blogs I've read on this error provide steps to ensure the SQL Server is configured properly).
Noticing the Named Pipes Provider portion of the error message, I guessed that maybe this user's computer or network was causing it to attempt connection via pipes rather than TCP, so I did try configuring the server to allow BOTH TCP/IP and Named Pipes for remote connections, where it was previously set to TCP/IP only. The error continued for this one user after changing this setting.
So now I'm left to brainstorm about what could be special about this one user's computer / software / internet connection that would hinder it from being able to connect to our SQL Server.
Our connection string does use our server's URL (not IP address), and I wondered if his laptop was having problems finding it by that address. However, he was able to access a website hosted from the same URL, so I guess the problem is somewhere else.
Any ideas would be greatly appreciated. Thanks!
You've probably long since solved this problem by now or moved on, but for those having similar problems with the Error 40/named pipes issue when connecting to a SQL server instance, the following simple solution worked for us:
You can force your client program to use TCP (or named pipes, or other available methods) by adding a prefix in your connection string.
For the .NET SQLConnection example, specify in the SQLConnection's connection string like so:
Server=tcp:192.168.0.1;Integrated Security=SSPI; database=sampledb
See this blog entry for more info.
Is it possible that they are being blocked by the hotel's firewall, which may only allow traffic on certain ports?