1 Reply Latest reply on Aug 2, 2012 12:42 AM by Ashok.Ora-Oracle

    Issue with DB_DUPSORT


      I am a large paying customer, I have been awaiting response from Oracle on my work-stop issue (Service Request 3-6016863631, Sev 2. "Expected" response time "supposed to be" 24 hours, its been well over that now.

      Okay, I have a primary table with DB_CREATE | DB_AUTO_COMMIT | DB_THREAD of type DB_BTREE.
      I have 10 secondary tables and the issue I am having is after I just added the 10th.

      They all also use DB_BTREE and DB_CREATE | DB_EXCL.

      I am using version 5.3.15 (not found on BDB download website anymore!) because I recently added my own feature in C++ that requires use of DB_DBT_MULTIPLE in the 10th secondary table I added.

      Following are my issues, in order of highest priority first:

      1) Does DB_DUPSORT work? For every secondary index, I set this flag secondaryDb->set_flags(DB_DUPSORT). This is many years old code ever since we used 4.4.20 BDB version. Many of my secondary indices do have duplicate keys BUT I get "DB_KEYEXIST" error if I have duplicate key values in the new (10th) secondary index. Nothing out of ordinary for this new index. Is this a bug? Note that when I prevented duplicate key values, everything works including the next issue I report below.

      2) In a separate install, I get DB_SECONDARY_BAD error repeatably. I suspect none of the 4 possible causes reported in this forum for this issue to happen. I want to know all possible (is there a 5th?) root causes for DB_SECONDARY_BAD error. I know what it means but suspect the BDB library has a bug in it.

      3) Is DB_KEYEXIST always a valid error? I read in another forum and in BDB documentation that this error code is returned for "convenience" by BDB library because it is "hard" (??) to return the real error... CAN I IGNORE THIS?

      4) The operation to "associate()" a secondary index - is it a blocking operation and guaranteed to be so?

      PLEASE HELP (and sorry for ambiguous language - I am new to BDB and also don't have a database background...)