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 theSun 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
