Knut Anders Hatlen <[EMAIL PROTECTED]> writes: > DerbyNetClient/metadata.out is for jdk<=1.3 > DerbyNetClient/jdk14/metadata.out is for jdk14 and jdk15 > DerbyNetClient/jdk16/metadata.out is for jdk>=1.6
I see, thanks for fixing this. So just to confirm: If you modify the output from metadata.java you need to run (and possibly update the master for): metadata.java, jdk1x, Embedded metadata.java, jdk1x, DerbyNet metadata.java, jdk13, DerbyNetClient metadata.java, jdk14(5), DerbyNetClient metadata.java, jdk16, Embedded metadata.java, jdk16, DerbyNet metadata.java, jdk16, DerbyNetClient odbc_metadata.java, jdk1x, Embedded odbc_metadata.java, jdk1x, DerbyNet odbc_metadata.java, jdk13, DerbyNetClient odbc_metadata.java, jdk14(5), DerbyNetClient odbc_metadata.java, jdk16, Embedded odbc_metadata.java, jdk16, DerbyNet odbc_metadata.java, jdk16, DerbyNetClient Upgrade_xx.java, jdk1x, Embedded Upgrade_xx.java, jdk16, Embedded And when the Upgrade test starts working with the NetworkServer we get another five cases? > Do you understand why the lastGetXXXResultSet_ variables are there in > the first place? No. > There are 15 of them, but none of them is ever accessed. I have > removed them in my sandbox and started a derbyall. If it doesn't > break anything, I think I will file a JIRA to get rid of them. Sounds good to me. -- dt
