db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <a...@golux.com>
Subject Re: Documentation questions for admin manual
Date Wed, 10 Nov 2004 17:44:58 GMT
sissonj@insession.com wrote:
> Is this a bug?  Should error 42X05 have been returned even on the first 
> insert attempt?

Technically speaking, no, I don't think is a "bug" per se, because the 42Y07 that you're seeing
corresponds to the 
expected Derby behavior in the scenario you described.  What's the expected behavior?  Well,
it's pretty much exactly 
what you described, which is reiterated in the following post, which is copy-pasted from a
post to the user's list back 
on 09/29 by Dan Debrunner: (anything I've added/marked up is enclosed in square brackets)

[ Begin quote ]

The current schema for any connection defaults to a schema corresponding to the user name,
in this case [WKPOINT]. If no 
user name is supplied then the user name (and hence current schema) defaults to APP. [ NOTE:
User name defaults to APP 
for _embedded_ Derby--but for Network Server, one isn't supposed to be able to connect without
a user name, so there is 
no "default"--schema will always be the user name. ]

However even though the current schema is set to the user name, that schema may not exist.
A schema is only created by 
CREATE SCHEMA or creating an object (table etc.) in that schema (this is implicit schema creation).
Thus in your case 
the schema [WKPOINT] does not exist.

The one exception to this is the APP schema, which is always created, though applications
should not depend on that.

So you will see the schema not exists error if your application tries to access the current
schema before any objects 
have been created in it.

[ end quote]

So in a word, we _expect_ to see 42Y07 the first time, because the it IS in fact the case
that the schema does not 
exist.  Once you create a table, the schema is created implicitly--so subsequent attempts
to reference a non-existent 
table will pass the "42Y07" check (because the schema now exists) and then fail with 42X05.

I.e. it's a matter of precedence: Derby checks for the schema first, and _then_ checks for
the table name, which makes 
sense since we can't verify the existence of the table unless we know what schema it's in.
 It's possible (and valid) to 
just return a "table not found" error if the schema doesn't exist, but "schema not found"
is a more accurate description 
of the problem...

>>**Q2** Is the documentation for the section "Encrypted UserID and 
>>Password" out of date?  Do you need the IBM JCE if you are running the 
> Sun JRE 1.4?

While Derby embedded supports the "encryptionProvider" connection attribute to specify a non-IBM
encryption provider 
(such as Sun's), the Network Server currently does not.  A glance at the java/drda/org/apache/derby/impl/drda
file shows 
that "IBMJCE" is actually hardcoded into the server.

That is something that will need to change at some point; not sure how hard/easy it would
be to change the Server to 
accept other encryption providers, but it might be worth filing a JIRA enhancement request...?


View raw message