data_engine issues a "General network error" alarm

Document ID : KB000034412
Last Modified Date : 14/02/2018
Show Technical Document Details

Issue:

The data_engine may generate the following alarm for a general network connection error.  
[Microsoft OLE DB Provider for SQL Server] [DBNETLIB][ConnectionRead (recv()).]General network error. Check your network documentation.
 
Additionally, you may see the following similar errors in the data_engine log:
de: ADO_BulkInsert::Commit - failed for RN_QOS_DATA_0011 
de: Commit - ERROR: Code=0x80004005 Source=Microsoft OLE DB Provider for SQL Server Description=[DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation. 
de: QoSInsert::Commit - failed for one or more of the bulk containers, save data and release connection

Cause:

This is most likely to happen during the UIM housekeeping procedures which, among other things, are reindexing the tables at the same time the data_engine is bulk-inserting new records into the tables.
 
In this situation, the bulk insert contains a row for an insert on a locked object that is being reindexed. The data_engine detects this, and saves all of the existing bulk insert packages.  It then reinitializes the connection to the database to make sure there isn't a problem, inserts the saved bulk packages, and then continues processing the data. No data are being lost in this process. This is behavior by design, and has been implemented to catch the several hundred error conditions which can be generated from the ADO layer, if something goes wrong. 
 
By default, these alarms are issued with severity = critical. There is an option to set the alarm_severity flag in the raw-configure module of the data_engine to raise these alarms with a different alarm severity level if that's desirable. But the drawback is of course that you might get into a situation where the ADO layer generates a generic error message which you might want to give attention. Unfortunately we're unable to control the messages provided by this layer, so we just present them when they come. 
 
These errors could also simply be caused by a brief interruption in the connectivity to the SQL Server or when SQL Server is in recovery mode and not accepting any connections to it. 
 

Resolution:

As long as this does not recur with any frequency, you should not be too concerned. If it reoccurs often, then it may require further investigation.