Jim,

> Tom, I don't think this is the way it should be done. I would be
> much happier if a statement exported a token that could be used for
> a subsequent cancel operation (token are never reused). The token
> solution plays nicely with virtual system status tables, is free of
> race conditions, and doesn't suffer the complications of handle
> reuse.

When does application obtains the token? Prior to the
isc_dsql_execute2 call? Should it then pass the token into the call?

If that's the case, I think Tom's proposal can be relatively easily
extended - we have to introduce one more flag for isc_dsql_sql_info
which would return unique token on each call. Application should pass
this token then into isc_dsql_execute3 (new call with one more
parameter). After that isc_dsql_cancel_statement uses the token
instead of handle to cancel that particular request.

The idea with the abort flag remains there, the only part that changes
is how the running request is identified - by token or by statement
handle.

Did I miss something?

Roman