[EMAIL PROTECTED] writes:

> "Knut Anders Hatlen (JIRA)" <derby-dev@db.apache.org> writes:
>
>>     [ 
>> http://issues.apache.org/jira/browse/DERBY-924?page=comments#action_12373839 
>> ] 
>>
>> Knut Anders Hatlen commented on DERBY-924:
>> ------------------------------------------
>>
>> The patch looks very good. There are however two issues that I would
>> like to have resolved before I commit the patch.
>>
>> 1) In DatabaseMetaData.getFunctionsX() you have this comment:
>>
>>        // Uncomment the following line when DERBY-970 is committed
>>        // checkServerJdbcVersionX() 
>>
>>    Since your patch is likely to get into trunk before my DERBY-970
>>    patch, please copy checkServerJdbcVersionX() into your patch and
>>    enable the check.
>
> Well, I tried applying that part of your 970 patch to my sandbox, but
> since clientmessages_en.properties has been removed and the messages
> in it given new messageIds, it was impossible :(

Oh, I'm sorry! I had forgotten that the 970 patch was outdated. When I
wrote the comment I thought that it was just a simple copy and paste
job. Now that it turns out that it's not that simple, feel free to
ignore my comment! :)

If you update the metadata test and canons as suggested, I'll commit
the patch with the check commented out. I'll try to update my 970
patch and enable the check when I have resolved the i18n conflict.

> When you coded your patch, SQLState.java looked as follows:
>
>      String NOT_IMPLEMENTED                                          = 
> "0A000.S";
>      String JDBC_METHOD_NOT_IMPLEMENTED                              = 
> "0AX01.S";
> +    String JDBC_METHOD_NOT_SUPPORTED_BY_SERVER                      = 
> "0AX02.S";
>
> Since then NOT_IMPLEMENTED and JDBC_METHOD_NOT_IMPLEMENTED has both
> gotten new ids (with the same 5 char prefix):
>
>     String NOT_IMPLEMENTED                                          = 
> "0A000.S";    String JDBC_METHOD_NOT_IMPLEMENTED                              
> = "0A000.S.1");
>
> So clearly your proposed id doesn't quite fit in. Do you have another
> suggestion? "0A000.S.2" maybe?

Yes, I think 0A000.S.2 should be fine. Thanks for the research!

-- 
Knut Anders

Reply via email to