Error "Communication link failure" or "SQLState 08501 " When Refreshing an Extract

Published: 01 Apr 2014
Last Modified Date: 23 May 2019


When refreshing an extract published to Tableau Server on Tableau Server, the following error message may be received:
com.tableausoftware.nativeapi.dll.DataSourceException: Communication link failure
 Log files may include following error:
--- ODBC Error -------------------------------------------------------------
File:         db\ODBCProtocolImpl.cpp, Line: 2524
Error Code:   -1 (SQL_ERROR)
2338: -------------
2338: Error Record: 1
2338: Description:  'Communication link failure'
2338: Native Error: 14
2338: ----------------------------------------------------------------------------

Additionally, the same error might occur when refreshing a published data source from Tableau Desktop.


  • Tableau Server
  • Tableau Desktop
  • Netezza
  • Microsoft SQL Server
  • Teradata


Work with your IT team to determine if there are interruptions to network traffic, network congestion, high server load on the datasource, other network disruptions, or hardware issues between your systems that are causing the connection to be lost.


The issue may be related to network congestion, high server load, or other network or hardware issues. 

Additional Information

For additional information about this topic, see the following articles and information below. 
Specifically for Teradata data sources. a network communication failure can occur due to a variety of reasons. Here is a list of common causes of connectivity problems, in order from most likely to less likely:
  1. The Teradata session was forcibly logged off by Teradata Viewpoint, Teradata Manager, PMON, or some other administrator process that checks for session inactivity and aborts idle sessions. This can be checked by examining /var/log/messages on the Teradata Database node, to look for messages that indicate that a session was aborted. This is a common problem for JDBC connections in a connection pool, because JDBC connections in a connection pool may spend a significant portion of their lifetime being idle. The Teradata Database administrator should not forcibly log off idle Teradata sessions that are pooled JDBC connections, because that defeats the purpose of the JDBC connection pool.
  2. Network problem and/or transient network failure. This can include situations such as a laptop switching from a wired to a wireless network connection (or vice-versa), or connecting to, or disconnecting from, a VPN.
  3. Faulty network hardware, such as a faulty switch, router, or load balancer.
  4. Teradata Database restart occurred. This can be checked by examining /var/log/messages on the Teradata Database node, to look for messages that indicate that a Teradata Database restart occurred.
Did this article resolve the issue?