Thanks Army, for going through the wiki page and reviewing it.
I was thinking of using the character set of the schema where the statement
is prepared. Your example demonstrates that from user point of view, this
will be easier to understand and easier for us to document.
I will add your comment to the wiki page and address it at the end of the
day along with other comments if nonone has objection to this approach.
Mamta
On 4/3/07, Army <[EMAIL PROTECTED]> wrote:
Thank you very much for the wiki page, Mamta. It is indeed very helpful!
Mamta Satoor wrote:
> The character set of the schema the function is defined in. That keeps
it
> least confusing and easier for the users to understand.
One question similar to Dan's, except mine is w.r.t:
> 8)JDBC parameters (ie. ?) where the type of the parameter is a character
> type will have the same collation as current schema's character set,
based
> on 3) above.
Since a parameter maker does not have a "defined" schema, does "current
schema"
mean the schema when the statement is prepared, or the schema when it is
executed?
For example I can do the following in JDBC:
// Default schema ("APP").
PreparedStatement ps = conn.prepareStatement(
"select tablename, tabletype from sys.systables where tablename =
?");
ps.setString(1, "Acorn");
ResultSet rs = ps.executeQuery();
while (rs.next())
System.out.println(" -=> " + rs.getString(1) + " - " +
rs.getString(2));
// Change current schema.
s.execute("set schema sys");
rs = ps.executeQuery();
while (rs.next())
System.out.println(" -=> " + rs.getString(1) + " - " +
rs.getString(2));
If we take "current schema" to mean the "schema when the statement is
executed"
then the first statement will fail (comparison of different collations))
whereas
the second one will succeed.
If "current schema" means the "schema when the statement is prepared" then
both
of the above statements would fail (because there's no CAST on the
syscol). That
consistency would probably be a good thing (less confusing for users).
Army
