Barry Lind wrote:
> The implementation in the current driver is such that you need to
> enable the use of server side prepare on a statement by statement
> basis (default is not to use it). So you should only enable if for
> those statements for which it will work. To illustrate the problem
> here is an example:
>
> pstat = conn.prepareStatement("insert into foo values (?); update bar
> set y = ?;);
>
> When run in server prepared mode this will issue the following
> statements to the server:
>
> prepare abc(int, int) as insert into foo values ($1); update bar set y
> = ($2);
>
> which will fail since the prepare statement is ended by the first
> semicolon. So this would be an example of a JDBC prepared statement
> that works fine currently but would fail when used with server side
> prepared statements.
Is the driver's mode set using a URL argument or an API call? I thought
I saw mention of a URL argument. Is the API call something that
persists between connection uses? We use a connection pool and I want
to get the right semantics for the use of this feature.
Personally, I'd prefer that the server scan for a non-quoted semicolon
and revert to non-prepared' operation. The cost of the extra scan is
likely to be minimal and would allow those folks who use a connection
pool to use this feature and have it work when it can and not interfere
when it might. I am guessing that you may have already parsed the
statement looking for ?'s
If so, wouldn't the supression of the 'prepare' be relatively
straight-forward?
Charlie
--
Charles H. Woloszynski
ClearMetrix, Inc.
115 Research Drive
Bethlehem, PA 18015
tel: 610-419-2210 x400
fax: 240-371-3256
web: www.clearmetrix.com