:: No. So, if you open your "select blah from ..." it will
:: just run forever if you never commit it. If it's a
:: read-write transaction (the default) it will cause the TSB
:: to grow and grow and grow until, ultimately, it asks for
:: resources it can't get. Boom. (You're not supposed to run
:: a read-write transaction for an uncontrolled long time...)

This goes back to my question about specifing the read flag - what does it
actually do? Is it "faster" / "Smaller" than specifying write on all
transactions?

:: Ummm...well, I don't know quite how you are doing it
:: now...if you don't know what the .NET driver is doing, best
:: you join the firebird-net-provider list and ask there.

AFAIK it does wrap everything in transactino if you don't, although I've
asked over there to be sure.

:: If it can return an error that it knows about, it does. But
:: we're talking here about the operating system shutting down
:: the service. How could the server respond with a message if
:: it has been killed? How would the server know that the
:: system is going to deny it resources?

If it's the TSB - it should monitor it a bit. The server should not allow
such a huge hole that any connectino can crash the whole server just by:
Begin trans
Run a bunch of stuff...

Boom - WHOLE server dies.

:: It won't stop your application from bloating the TSB if
:: that's what your application wants to do....

That's fine - but it should kill my applicatinos connectino - not just die.
Imagine if Windows worked this way - the OS died every time an application
burped. Ahh wait - Window 3.1 did.. And remember what a mess that was?