>>>>>>>>>>>> Myrna van Lunteren (JIRA) wrote (2006-05-04 17:47:27): > [ > http://issues.apache.org/jira/browse/DERBY-7?page=comments#action_12377852 ] > > Myrna van Lunteren commented on DERBY-7: > ---------------------------------------- > > Hi Berndt, > > I happened to spot the following in your check-in for revision 399657 for the > test jdbcapi/resultset.java: > > + } catch(SQLException ex){ > + if (ex.getSQLState().equals("22005")) > { > + if (s.getBytes (i) != null) > + row.append(new String(s.getBytes(i))); > + else > + row.append(s.getBytes(i)); > + } else throw ex; > + } > > I think what has happened here is that you applied original patch of > DERBY-7 to 10.1.
No, I did a svn merge -r227280:227281 ../trunk > However, the test resultset.java has since had some work done on it, > and I'm specifically concerned that you may have missed the changes > I worked on for DERBY-903, which were committed with revision 378337 > and 379643. I think the explanation is that DERBY-7 was committed long before DERBY-903, but now they were applied to 10.1 in the opposite order. > This eliminates the use of the constructor 'new String(bytes[]), > which is non-portable...It constructs a string by decoding the bytes > using the default platform charset. This can lead to encoding > related problems. For this case, you should probably use the > constructor that takes in the encoding. ie new String(byte[], String > charsetname). > > Can you please rework this section of resultset.java to not use an > encoding-safe mechanism? Just compare with the current 10.2 > resultset.java... Thanks for spotting this one, I'll look into it. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
signature.asc
Description: Digital signature
