I have the same problem as described here: http://community.qlik.com/message/273996. In my case, I have a Configurable ODBC Directory pointing to a SQL Server database. If at any point, an issue occurs with the connection to SQL Server, the directory stops working and requires either a restart of the QlikView Directory Service Connector service or a re-apply of the settings on the directory.
Here is what the directory service log shows repeatedly once this has become an issue:
1/4/2013 09:12:30.3490000 Error (Database.DatabaseProvider) DB-search wasn't successful:
System.InvalidOperationException: ExecuteReader requires an open and available Connection. The connection's current state is closed.
at System.Data.Odbc.OdbcConnection.SetStateExecuting(String method, OdbcTransaction transaction)
at System.Data.Odbc.OdbcCommand.ValidateConnectionAndTransaction(String method)
at System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader, Object methodArguments, SQL_API odbcApiMethod)
at System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader)
at System.Data.Odbc.OdbcCommand.ExecuteReader(CommandBehavior behavior)
at Database.DatabaseProvider.DoSearch(String pattern, eSearchType searchTypes, String otherAttribute)
It has been suggested to schedule a regular restart of the QlikView Directory Service Connector service. That is not satisfactory because a connectivity issue can occur anytime for various reasons and this results in failed authorizations--users cannot access QVW files when this occurs. The QlikView Directory Service Connector service should be designed to attempt to reconnect automatically. In my view this is a serious bug with the Configurable ODBC Directory functionality.
I am running an enterprise license of QlikView Server x64 v11.0.11282.0 (11 SR1) on Windows Server 2008. The post above relates to version 11 SR2 so obviously it was not fixed in SR2. I looked at the release notes for 11.2 and didn't see anything that would indicate that this was fixed.
Is this issue a known bug and/or are there plans to fix this in an upcoming service release?