Thanks for report, it's one of known problem which I have on my radar - http://wiki.netbeans.org/DatabaseKnownProblems
I'm considering them while planning next release of NetBeans.

You can actually add connections, which differ only in the schema to the connection list, but this is not correctly reflected in the connection list - I tested against an informix database and used the current nightly build available for download. I still struggle to understand the structure of the whole architecture (my first impression: it's needlessly complex!).

Part of the problem lies in org.netbeans.api.db.explorer.node.NodeProvider#getNodes:

The return value is documented as:

"the list of nodes that contain a lookup containing the data object"

while the comment says:

"Get the list of nodes that contain a lookup that in turn contains an object with a matching hash code."

I think the implementor misunderstood hashCode. The contract makes no guarantes to the implementation and an implementation, that always return a fixed integer value would be a valid implementation. The equals method should be the basis for an equality check. So:

--- nb-trunk-orig/db/src/org/netbeans/api/db/explorer/node/NodeProvider.java	2011-11-22 06:15:00.000000000 +0100
+++ nb-trunk/db/src/org/netbeans/api/db/explorer/node/NodeProvider.java	2011-11-23 20:53:05.000000000 +0100
@@ -162,7 +162,7 @@
         synchronized (nodeSet) {
             for (Node child : nodeSet) {
                 Object obj = child.getLookup().lookup(dataObject.getClass());
-                if (obj.hashCode() == dataObject.hashCode()) {
+                if (obj.hashCode() == dataObject.hashCode() && obj.equals(dataObject)) {
                     results.add(child);
                 }
             }
mblaesing@prometheus:~/src$ 


This fixes my problem field, which is only part of the original reportes problem. I didn't test the Entity-Class generation, but this patch would at least solve part of the problem.

Just tested entity generation and it worked on both connections, each showing the tables of the corresponding schema. So making the changes from comment #2 solves this bug.

Thanks for the hint.
core-main/rev/c8942c600546