I get this error too from time to time.
When using pooling, after the firebird server is restarted it's immposible
to establish a new connection to the serwer.
Probably the provider pulls a bad connection from the pool and tries to use
it despite its being broken.
Cheers.
Michał
2015-01-23
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ří
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
from
databases that dont have anything to do with this problem, but is on the
same server
*De:* Michał Ziemski [mailto:m...@e-adm.pl]
*Enviada em:* sexta-feira, 23 de janeiro de 2015 12:14
*Para:* For users and developers of the Firebird .NET providers
*Assunto:* Re: [Firebird-net-provider
Hi!
I've made a pull request on github with my proposal.
Cheers!
Michał
2015-10-14 7:52 GMT+02:00 Jiří Činčura <j...@cincura.net>:
> On Tue, Oct 13, 2015, at 22:53, Michał Ziemski wrote:
> > I would rather also test connectionString.MaxPoolSize with the
> > &
Hi!
IMHO you won't be able to handle all the corner cases without full grammar
parser.
For example consider a "SET TERM" inside an "EXECUTE BLOCK".
Lacking the grammar understnding you won't recognize that as an invalid
term in the execute block and
you'll simply cut the block in half. So the
ing.MaxPoolSize mean
"how
many connections you would like to have at hand when you're working with
the database"
rather than "how many concurrent connections would you like to allow", which
I think is closer to the goal of the pool.
Such behaviour would be much more predicta
