Re: [Derby-655] : getImportedKeys returns duplicate rows in some cases

[Satheesh Bandaram]

Mamta Satoor wrote: It seems that there is now a separation of congomerates into logical congomerates (rows in SYSCONGLOMERATES) and physical conglomerates (files on disk). But what you describe has the CONGLOMERATEID being the physical identifier when it seems it should be a unique identifier for the logical conglomerate. I would have thought the CONGLOMERATENUMBER would be the physical identifier, thus in the situation you describe I would expect two rows in SYSCONGLOMERATES with the same CONGLOMERATENUMBER but unique CONGLOMERATEIDs.   The duplicate rows do have the same CONGLOMERATENUMBER which corresponds to the physical conglomerate. But the CONGLOMERATEID which could be thought of as logical conglomerate is not unique in SYSCONGLOMERATES. If we change the CONGLOMERATEID to be a unique key in SYSCONGLOMERATES by changing the code in CreateIndexConstantAction somehow, then we will not have to change the metadata query in anyways and the reference manual will not have to change for the release in which the fix will go. If we decide not to backport the fix in older Derby releases, then we should fix the reference manual for those releases. This sounds like the right approach... I think conglomerateId should be unique, though we may not be able to mark it as such internally now.... to support upgrading 10.1 or earlier databases which may have duplicate values. There seems to be couple of other metadata queries that also depend on conglomerateId being unique, so it would be good to make conglomerateId unique again. Satheesh Thanks, Mamta Thanks, Dan.