Subject Re: JayBird: Problems with Prepared Statements
Author pifproject
Hello Rick,
thanks for your replies!

> In order to support executing unprepared SQL, prepared statements
> are converted to a String so both prepared and "free-form" SQL
> gets passed to statementExecutor(String sqlStatement)

Kind of. It's not because of supporting one type of SQL statements
or/after the other, it's because of supporting both types with a
single 'statementExecutor()' method.

> What if instead all Strings get prepared by
statementPreparer(String sqlStatement)
> and then both types of statements just get executed

Well that's somehow an improvement suggestion for the SQL execution:
but how can you pass a prepared statement to the statementPreparer()
method, when you cannot convert this very prepared statement to String?

> I vote for keeping it vendor specific. I access all vendor stuff
> within wrappers anyway

As I have mentioned in my previous reply, the idea for solving it
vendor-specific due to standardization concerns seems quite
reasonable. I have asked for the described feature in order to be able
to provide a more general-purpose solution, which will be nice for the
end users.

- Roman wrote:
> > Please fill the feature request at, so we
> > do not forget it before the next RC and/or final release.
> > Just type few words - Yahoo might decide to remove their
> > message database.
- me:
> Okay, I'll try to formulate something as a description.

Here it is: