> > If I read the documentation correctly, a statement which performed
> > (say) a SELECT against a table that
> > follows a NATURAL scan, which is 'paused' awaiting the next Fetch, would
> run into the timeout, even > though there is no "cost" to the engine of
> waiting.
> >
> > Am I correct?
>
> Yes.
That doesn't seem quite right.
I always think of Timeout as been a measure of the amount of time the engine is
busy/working. Otherwise, why would "milli-second" based Timeout value have any
use.
While waiting for a "fetch" the engine is doing "nothing", so IMO, it should
not factor into the timeout.
{I have done some searches on how other engines handle this issue but haven't
not found any good details/examples}
> > Separately, it would be "a good thing" if the Timeouts could be set in
> > Trigger or SP -- perhaps via
> > special "SQL_Timeout" RDB$Context for the "User_Session" and
> "User_Transaction" namespaces.
>
> For what goal ?
To allow for the timeout to be customized.
Arguably, setting the "SQL_Timeout" value in the > "User_Transaction" namespace
would allow the timeout value for the *current transaction* to be overridden in
code, without the need for API settings.
Similarly, for the "User_Session", which would, of-course, apply to the next
transactions of the current session/connection.
Sean
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
