On Aug 29, 1:12 pm, bry...@archtest.com wrote:
> When implementing database mirroring using SQL 2005, our .NET
> Framework 2.0 Windows Forms Application clients are intermittently
> receiving the following error:
>
> Internal .Net Framework Data Provider error 6.
> at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection
> owningObject)
> at
> System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection
> owningObject)
> at
> System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection
> owningObject)
> at
> System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection
> owningConnection)
> at
> System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection
> outerConnection, DbConnectionFactory connectionFactory)
> at System.Data.SqlClient.SqlConnection.Open()
>
> AND
>
> The SQL server log on the mirror server indicates that at the time the
> clients are receiving this error, the following error is also being
> logged:
>
> Login failed for user DOMAIN/user
> Error 18456, Severity: 14, State: 16.
>
> AND
>
> at the same time, a "Success Audit" entry, in the Security section of
> the mirror machine's event log is also logged. This is happening to
> random clients at random times, throughout the entire range of modules
> in our application. The clients can be local to our network,
> connected via VPN or connected over WAN.
>
> We have attempted mirroring on two mirror servers, one inside a
> virtual machine, and one living inside its own box, both yielding the
> same errors to our clients.
>
> The software is as follows:
>
> PRINCIPAL SERVER: SQL2005 9.0.3042 / WINDOWS SERVER 2003 SP1
> (Running on its own machine)
>
> 1st TEST USING MIRROR SERVER: SQL2005 9.0.3042 / WINDOWS SERVER 2003
> SP1
> (Running inside a virtual machine)
>
> 2nd TEST USING MIRROR SERVER: SQL2005 9.0.2050 / WINDOWS SERVER 2003
> SP2
> (Running on its own machine - I wanted to eliminate any problems
> using a virtual machine)
>
> WITNESS SERVER: <none>
>
> CLIENT CONNECTION STRING: Data Source=PrincipalServer;Initial
> Catalog=database;Integrated Security=True;Max Pool
> Size=200;Asynchronous Processing=True;Packet Size=26000
> (Note that we do not have a failover server name included in the
> client connection string)
>
> We have approximately 200 clients and approximately every 30 minutes
> or so error 6 will occur, and even though the error is related to a
> failure audit on the mirror server, it will not allow a connection to
> the primary server. This is of course interfering with our production
> environment.
>
> For testing and to eliminate security issues, we have temporarily
> assigned all users server administration (the sysadmin server role)
> rights to the mirror server, but with no change in the amount of .NET
> error 6 errors.
>
> Removing database mirroring eliminates the problem entirely. Also,
> there are no errors being logged on the principal server.
>
> Other than abandoning our goal of implementing mirroring, can anyone
> suggest a solution to this problem?
>
> Any help would be greatly appreciated!
>
> Bryan

On Sep 6, 1:56 pm, jor...@gmail.com wrote:
> On Aug 29, 1:12 pm, bry...@archtest.com wrote:
>
>
>
>
>
> > When implementing database mirroring using SQL 2005, our .NET
> > Framework 2.0 Windows Forms Application clients are intermittently
> > receiving the following error:
>
> > Internal .Net Framework Data Provider error 6.
> > at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection
> > owningObject)
> > at
> > System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection
> > owningObject)
> > at
> > System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection
> > owningObject)
> > at
> > System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection
> > owningConnection)
> > at
> > System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection
> > outerConnection, DbConnectionFactory connectionFactory)
> > at System.Data.SqlClient.SqlConnection.Open()
>
> > AND
>
> > The SQL server log on the mirror server indicates that at the time the
> > clients are receiving this error, the following error is also being
> > logged:
>
> > Login failed for user DOMAIN/user
> > Error 18456, Severity: 14, State: 16.
>
> > AND
>
> > at the same time, a "Success Audit" entry, in the Security section of
> > the mirror machine's event log is also logged. This is happening to
> > random clients at random times, throughout the entire range of modules
> > in our application. The clients can be local to our network,
> > connected via VPN or connected over WAN.
>
> > We have attempted mirroring on two mirror servers, one inside a
> > virtual machine, and one living inside its own box, both yielding the
> > same errors to our clients.
>
> > The software is as follows:
>
> > PRINCIPAL SERVER: SQL2005 9.0.3042 / WINDOWS SERVER 2003 SP1
> > (Running on its own machine)
>
> > 1st TEST USING MIRROR SERVER: SQL2005 9.0.3042 / WINDOWS SERVER 2003
> > SP1
> > (Running inside a virtual machine)
>
> > 2nd TEST USING MIRROR SERVER: SQL2005 9.0.2050 / WINDOWS SERVER 2003
> > SP2
> > (Running on its own machine - I wanted to eliminate any problems
> > using a virtual machine)
>
> > WITNESS SERVER: <none>
>
> > CLIENT CONNECTION STRING: Data Source=PrincipalServer;Initial
> > Catalog=database;Integrated Security=True;Max Pool
> > Size=200;Asynchronous Processing=True;Packet Size=26000
> > (Note that we do not have a failover server name included in the
> > client connection string)
>
> > We have approximately 200 clients and approximately every 30 minutes
> > or so error 6 will occur, and even though the error is related to a
> > failure audit on the mirror server, it will not allow a connection to
> > the primary server. This is of course interfering with our production
> > environment.
>
> > For testing and to eliminate security issues, we have temporarily
> > assigned all users server administration (the sysadmin server role)
> > rights to the mirror server, but with no change in the amount of .NET
> > error 6 errors.
>
> > Removing database mirroring eliminates the problem entirely. Also,
> > there are no errors being logged on the principal server.
>
> > Other than abandoning our goal of implementing mirroring, can anyone
> > suggest a solution to this problem?
>
> > Any help would be greatly appreciated!
>
> > Bryan
>
> Hi Bryan,
> do you sitll have this problem. did you ever find a solution. we are
> experiencing the same problem.
>
> I can't seem to find a solution anywhere!!!
>
> Cheers- Hide quoted text -
>
> - Show quoted text -