Thanks Army for the help regarding the schema error. I have raised http://nagoya.apache.org/jira/browse/DERBY-65 for the encryption problem.
Regards, John Army <[EMAIL PROTECTED]> wrote on 11/11/2004 04:44:58 AM: > [EMAIL PROTECTED] 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...? > > Army
