Maybe a better approach would be to catch the exception when writing to a
socket and in that case flush the pool?
Polling on every connection every 2 secs is a major overhead (especially
for server uses with many connections to multiple databases).
Cheers!
Michał
2015-01-27 12:56 GMT+01:00
I am still trying to understand why it is being considered expected
behavior if due to this issue all of my 122 clients need to be re-start
their application every time the Firebird Server is Stop/Start or every
time that we have any network issue.
You live in a dream. There was never
Let me copy, once again, the source code of the SW that is not work. Note the
I am always open the Polling connection according the documentation (
https://msdn.microsoft.com/en-us/library/8xx3tyca(v=vs.100).aspx ) and it
was broken since the version 4.6.0.0:
===
using
I have other applications in use with Postgree and SQL Server, and work
perfectly in Firebird do not understand why it should be different.
-Mensagem original-
De: Luciano Mendes [mailto:luronu...@gmail.com]
Enviada em: domingo, 25 de janeiro de 2015 10:17
Para:
Don't change anything in your SW because this is not as issue of it.
Use the ADO.NET Provider v.4.5.2.0 that is the lastest version that works
fine.
I am still trying to understand why it is being considered expected
behavior if due to this issue all of my 122 clients need to be re-start
their
But in this case the pooling problem give the correct would not try a new
connection from the beginning and no longer use the pooling?
-Mensagem original-
De: Jiří Činčura [mailto:j...@cincura.net]
Enviada em: sexta-feira, 23 de janeiro de 2015 09:56
Para: For users and developers of the
Or alternatively you could flush the pool.
Michał
2015-01-23 15:02 GMT+01:00 Nicolas F. Timmers nftimm...@hotmail.com:
But in this case the pooling problem give the correct would not try a new
connection from the beginning and no longer use the pooling?
-Mensagem original-
De: Jiří
