This error marked as solved on previous question with sybase 12 driver: http://sqlanywhere-forum.sap.com/questions/18867/invalid-request-on-pooled-connection
I receive the same error with sybase 16 driver: Message: System.Data.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details. ---> iAnywhere.Data.SQLAnywhere.SAException: Run time SQL error -- ERROR Assertion failed: 104909 (126.96.36.1998)[maindb] Invalid request on pooled connection at iAnywhere.Data.SQLAnywhere.SACommand._ExecuteReader(CommandBehavior commandBehavior, Boolean isExecuteScalar, Boolean isBeginExecuteReader) at iAnywhere.Data.SQLAnywhere.SACommand.ExecuteDbDataReader(CommandBehavior behavior) at System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior) --- End of inner exception stack trace --- at Silverbyte.ReceptionAnywhere.Repository.MainDbRepository.HandleException(String method, Exception ex) at Silverbyte.ReceptionAnywhere.Repository.MainDbRepository.GetGuestsClubs(List`1 guestsIds) at Silverbyte.ReceptionAnywhere.Application.ChekcInService.Get(GuestsArrivals request)
Notice that the db version is 188.8.131.528 and ado.net driver 16.0.20764 version.
asked 16 Nov '15, 08:42
If you can narrow this down to a small test case you may be able to capture enough detail through [.Net Tracing]
: http://SAP Sybase SQL Anywhere 16.0 » SQL Anywhere Server - Programming » .NET application programming » SQL Anywhere .NET Data Provider
answered 16 Nov '15, 13:58
Nick Elson S...
The fix mentioned in the other posting, was applied to both versions (12.0.1 and 16) and before the build you say you are using for the ado.net driver so that much should be in place. The fix does not prevent this assertion, but makes it benign (at the server) but is still throwable if the client side does something inappropriate.
Clearly we have the correct server version and build (from the 'Assertion failed' text). The assertion itself would also seems to be correct (correctly non-fatal at the server, and due to some illicit reuse attempt from the client side) so that leaves open many more questions about what is actually happening on the client side.
I guess there is still a chance that you are somehow picking up an older version of the .Net provider. You might want to make sure all .Net apps and all copies of Visual Studio are shutdown and [re-]run
to correct any mis-registered components in the Global Assembly Cache and the Windows Microsoft.NET machine.config file. I need be checking those to see what is registered to make sure they are in good shape and that this step corrected any issues.
After that if the problem persist we may have a new, undiagnosed issue and may need to get in deep into application code and find a way to mock this up.
The fact that this is being thrown from the _ExecuteReader( ) method seems particularily odd to me. That would seem something that is only possible if you have reused an SACommand and connection that has been disposed?
If no luck with any of this I would recommned narrowing this down to as few lines of code as possible and contact support to help with this.
answered 16 Nov '15, 13:29
Nick Elson S...