Known Limitations and Workarounds, PreparedStatement
PreparedStatement.setString() performs more slowly than PreparedStatement.setBytes(). Why?
This can occur when the SQL Server data type of your table's column is different than the type being used in your query.
For example, say you have a table in your SQL Server database with a column of type char or varchar, and the query in your Java code looks like this:
"SELECT * from mytable where mytext = ?"
If you use pstmt.setString(1, "99"); in your Java code, then JTurbo inserts the parameter and builds the query using 'N' like this:
... where mytext = N'99'
This forces SQL Server to do a conversion from nvarchar to the type of your table's column (char or varchar).
A conversion like this is expensive.
If you use pstmt.setBytes(1, "99".getBytes("8859_1")); in your Java code, then JTurbo inserts the parameter and builds the query like this:
... where mytext = 0x3939
which does not require a type conversion within SQL Server.
The only way that JTurbo's PreparedStatement could avoid prepending the 'N'
would be if it were to first ask SQL Server whether or not the
column type was nchar, nvarchar, or ntext.
Asking this for every sql query it builds could be very expensive.
Our recommendation is that you change your database column type to be one of the 'n' types: