On Mon, 21 Nov 2005, Mark Lewis wrote:
> Here's a thought; do you think it's feasible to detect cases where the
> protocol=3 driver throws an error due to invalid or ambiguous typing
> issues when the protocol=2 driver would just do the expected thing?
>
> Instead of throwing the error back to the user, could the driver then
> issue a 'describe statement' call, use the result to disambiguate the
> parameter settings, and re-issue the call? It increases the overhead
> but only for the error cases, and the result could be cached to avoid
> repeating that overhead.
>
There a number of problems with the fallback approach. First, since we've
got a server error that will necessitate the transaction be rolled back so
we'd have to establish a savepoint before every statement. Then you'd
have to detect an error condition as being related to type resolution
which isn't really clear. Even if this did work for people it certainly
wouldn't be optimal because you could end up doing a lot more work,
parsing twice and establishing and rolling back to savepoint, without
knowing it. Your application would look like it was working, but it's
certainly not how you want it to.
Kris Jurka
