Re: [U2] UV index with duplicate nodes
Look for a space or non printing character in the data. That would make it look the same but actually be unique. - Original Message - From: Richard Lewis rbl...@gmail.com To: U2-Users@listserver.u2ug.org Sent: Thursday, September 30, 2010 8:47 PM Subject: [U2] UV index with duplicate nodes We've just uncovered a rather unusual and unsettling situation. We have a file with a single index that has somehow gotten nodes with duplicate keys. A simple example would be having an index on ZIPCODE in a address database, and finding that there are _two_ nodes (records) in the index for ZIPCODE 12345, for example. The source records referred to in the nodes are not duplicated, but since most operations find the 'first' node, any source records referred to in the duplicate node appear to not exist in the index. LIST.INDEX fname ALL Alternate Key Index Summary for file fname File... fname Indices 1 (1 A-type, 0 C-type, 0 D-type, 0 I-type, 0 SQL, 0 S-type) Index Updates.. Enabled, No updates pending Index name Type BuildNulls In DICT S/M Just Unique Field num/I-type fieldnameANot Reqd YesYes ML N2 The file contains 6,539,233 records, with 574,547 unique values in fieldname (which is actually a single-valued field, and has been verified that each record's fieldname contains one and only one value). We found that 9 source records appear to have not been included in the index, but upon further research found the nodes with duplicate keys. We created an F-pointer to the index file itself (not normally recommended, but useful), then got the results like the following: LIST indexfile WITH @ID = 12345] F1 F2 fname. F1 F2 12345 987654 876543 12345-6789 765432 543219 12345 654321 We are having our UniVerse administrator ask our dealer for assistance, but were interested if any other users have had any recent similar experiences, or advice. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV index with duplicate nodes
This has been our issue in the past -- unless you look at that data with a HexEditor, it's not obvious. If you use the UniData AE Editor (now included with UniVerse) you can type a ^ (Shift 6 - Caret) and see non-printable characters. Once you know the culprit, you fix the source data and the index heals itself. David W. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Richard Brown Sent: Friday, October 01, 2010 6:02 AM To: U2 Users List Subject: Re: [U2] UV index with duplicate nodes Look for a space or non printing character in the data. That would make it look the same but actually be unique. - Original Message - From: Richard Lewis rbl...@gmail.com To: U2-Users@listserver.u2ug.org Sent: Thursday, September 30, 2010 8:47 PM Subject: [U2] UV index with duplicate nodes We've just uncovered a rather unusual and unsettling situation. We have a file with a single index that has somehow gotten nodes with duplicate keys. A simple example would be having an index on ZIPCODE in a address database, and finding that there are _two_ nodes (records) in the index for ZIPCODE 12345, for example. The source records referred to in the nodes are not duplicated, but since most operations find the 'first' node, any source records referred to in the duplicate node appear to not exist in the index. LIST.INDEX fname ALL Alternate Key Index Summary for file fname File... fname Indices 1 (1 A-type, 0 C-type, 0 D-type, 0 I-type, 0 SQL, 0 S-type) Index Updates.. Enabled, No updates pending Index name Type BuildNulls In DICT S/M Just Unique Field num/I-type fieldnameANot Reqd YesYes ML N2 The file contains 6,539,233 records, with 574,547 unique values in fieldname (which is actually a single-valued field, and has been verified that each record's fieldname contains one and only one value). We found that 9 source records appear to have not been included in the index, but upon further research found the nodes with duplicate keys. We created an F-pointer to the index file itself (not normally recommended, but useful), then got the results like the following: LIST indexfile WITH @ID = 12345] F1 F2 fname. F1 F2 12345 987654 876543 12345-6789 765432 543219 12345 654321 We are having our UniVerse administrator ask our dealer for assistance, but were interested if any other users have had any recent similar experiences, or advice. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV index with duplicate nodes
into determining exactly how long a rebuild of this particular index will take, as that seems like the best work-around for us at the moment. We are in the process of formalizing the steps we use to identify the problem, and codifying that in a process that can be run on every index we have, so that we can at least identify the scope of our issues and, if rebuild is the only remedy, make plans to schedule them regularly. If you would like to check your indexes, here are the steps we have found to be reliable: 1.Create an F-pointer to the index directly, named indexfile, with the Dict pointing to the dict of the data/source file. 2.SSELECT indexfile 3.SAVE.LIST XX 4.Create a DICT fname DUP dictionary item like this: a.0001: I b.0002: @2;@ID;@1...@2 c.0003: d.0004: e.0005: 3R f.0006: S 5.GET.LIST XX 6.LIST indexfile WITH DUP # “0” DUP 7.Note the ID’s listed (dup_id1, dup_id2, etc.). Use them as listing criteria as follows: a.LIST indexfile WITH @ID = “dup_id1]””dup_id2]” (etc.) F1 F2 Building a program to perform these tasks will be one of our next immediate steps. Any further suggestions or comments are most welcome! Sincerely Best Regards, Richard On Fri, Oct 1, 2010 at 7:39 AM, David Wolverton dwolv...@flash.net wrote: This has been our issue in the past -- unless you look at that data with a HexEditor, it's not obvious. If you use the UniData AE Editor (now included with UniVerse) you can type a ^ (Shift 6 - Caret) and see non-printable characters. Once you know the culprit, you fix the source data and the index heals itself. David W. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Richard Brown Sent: Friday, October 01, 2010 6:02 AM To: U2 Users List Subject: Re: [U2] UV index with duplicate nodes Look for a space or non printing character in the data. That would make it look the same but actually be unique. - Original Message - From: Richard Lewis rbl...@gmail.com To: U2-Users@listserver.u2ug.org Sent: Thursday, September 30, 2010 8:47 PM Subject: [U2] UV index with duplicate nodes We've just uncovered a rather unusual and unsettling situation. We have a file with a single index that has somehow gotten nodes with duplicate keys. A simple example would be having an index on ZIPCODE in a address database, and finding that there are _two_ nodes (records) in the index for ZIPCODE 12345, for example. The source records referred to in the nodes are not duplicated, but since most operations find the 'first' node, any source records referred to in the duplicate node appear to not exist in the index. LIST.INDEX fname ALL Alternate Key Index Summary for file fname File... fname Indices 1 (1 A-type, 0 C-type, 0 D-type, 0 I-type, 0 SQL, 0 S-type) Index Updates.. Enabled, No updates pending Index name Type BuildNulls In DICT S/M Just Unique Field num/I-type fieldnameANot Reqd YesYes ML N2 The file contains 6,539,233 records, with 574,547 unique values in fieldname (which is actually a single-valued field, and has been verified that each record's fieldname contains one and only one value). We found that 9 source records appear to have not been included in the index, but upon further research found the nodes with duplicate keys. We created an F-pointer to the index file itself (not normally recommended, but useful), then got the results like the following: LIST indexfile WITH @ID = 12345] F1 F2 fname. F1 F2 12345 987654 876543 12345-6789 765432 543219 12345 654321 We are having our UniVerse administrator ask our dealer for assistance, but were interested if any other users have had any recent similar experiences, or advice. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV index with duplicate nodes
Oh, I forgot to mention that we are on UV 10.3.2, HP-UX B.11.23 U. Thanks! Richard ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] UV index with duplicate nodes
We've just uncovered a rather unusual and unsettling situation. We have a file with a single index that has somehow gotten nodes with duplicate keys. A simple example would be having an index on ZIPCODE in a address database, and finding that there are _two_ nodes (records) in the index for ZIPCODE 12345, for example. The source records referred to in the nodes are not duplicated, but since most operations find the 'first' node, any source records referred to in the duplicate node appear to not exist in the index. LIST.INDEX fname ALL Alternate Key Index Summary for file fname File... fname Indices 1 (1 A-type, 0 C-type, 0 D-type, 0 I-type, 0 SQL, 0 S-type) Index Updates.. Enabled, No updates pending Index name Type BuildNulls In DICT S/M Just Unique Field num/I-type fieldnameANot Reqd YesYes ML N2 The file contains 6,539,233 records, with 574,547 unique values in fieldname (which is actually a single-valued field, and has been verified that each record's fieldname contains one and only one value). We found that 9 source records appear to have not been included in the index, but upon further research found the nodes with duplicate keys. We created an F-pointer to the index file itself (not normally recommended, but useful), then got the results like the following: LIST indexfile WITH @ID = 12345] F1 F2 fname. F1 F2 12345 987654 876543 12345-6789 765432 543219 12345 654321 We are having our UniVerse administrator ask our dealer for assistance, but were interested if any other users have had any recent similar experiences, or advice. Sincerely Best Regards, Richard Lewis IBM Certified Solutions Expert Nu Skin Enterprises ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV index with duplicate nodes
Does the correlative have any special coding in it? I would suggest deleting the index for this field recreate the field as a D type then add the field to the index again. Some correlatives don't give you what you would expect. Jerry Banker -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Richard Lewis Sent: Thursday, September 30, 2010 7:47 PM To: U2-Users@listserver.u2ug.org Subject: [U2] UV index with duplicate nodes We've just uncovered a rather unusual and unsettling situation. We have a file with a single index that has somehow gotten nodes with duplicate keys. A simple example would be having an index on ZIPCODE in a address database, and finding that there are _two_ nodes (records) in the index for ZIPCODE 12345, for example. The source records referred to in the nodes are not duplicated, but since most operations find the 'first' node, any source records referred to in the duplicate node appear to not exist in the index. LIST.INDEX fname ALL Alternate Key Index Summary for file fname File... fname Indices 1 (1 A-type, 0 C-type, 0 D-type, 0 I-type, 0 SQL, 0 S-type) Index Updates.. Enabled, No updates pending Index name Type BuildNulls In DICT S/M Just Unique Field num/I-type fieldnameANot Reqd YesYes ML N2 The file contains 6,539,233 records, with 574,547 unique values in fieldname (which is actually a single-valued field, and has been verified that each record's fieldname contains one and only one value). We found that 9 source records appear to have not been included in the index, but upon further research found the nodes with duplicate keys. We created an F-pointer to the index file itself (not normally recommended, but useful), then got the results like the following: LIST indexfile WITH @ID = 12345] F1 F2 fname. F1 F2 12345 987654 876543 12345-6789 765432 543219 12345 654321 We are having our UniVerse administrator ask our dealer for assistance, but were interested if any other users have had any recent similar experiences, or advice. Sincerely Best Regards, Richard Lewis IBM Certified Solutions Expert Nu Skin Enterprises ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV index with duplicate nodes
I assume you have tried rebuilding the indices? That usually fixes almost all of our issues with index problems. Otherwise I would delete the index and build it back again. If you need any code that we use just ask me and I can email it to you. -Chris From: jpb-u...@hotmail.com To: u2-users@listserver.u2ug.org Date: Thu, 30 Sep 2010 21:19:22 -0500 Subject: Re: [U2] UV index with duplicate nodes Does the correlative have any special coding in it? I would suggest deleting the index for this field recreate the field as a D type then add the field to the index again. Some correlatives don't give you what you would expect. Jerry Banker -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Richard Lewis Sent: Thursday, September 30, 2010 7:47 PM To: U2-Users@listserver.u2ug.org Subject: [U2] UV index with duplicate nodes We've just uncovered a rather unusual and unsettling situation. We have a file with a single index that has somehow gotten nodes with duplicate keys. A simple example would be having an index on ZIPCODE in a address database, and finding that there are _two_ nodes (records) in the index for ZIPCODE 12345, for example. The source records referred to in the nodes are not duplicated, but since most operations find the 'first' node, any source records referred to in the duplicate node appear to not exist in the index. LIST.INDEX fname ALL Alternate Key Index Summary for file fname File... fname Indices 1 (1 A-type, 0 C-type, 0 D-type, 0 I-type, 0 SQL, 0 S-type) Index Updates.. Enabled, No updates pending Index name Type Build Nulls In DICT S/M Just Unique Field num/I-type fieldname A Not Reqd Yes Yes M L N 2 The file contains 6,539,233 records, with 574,547 unique values in fieldname (which is actually a single-valued field, and has been verified that each record's fieldname contains one and only one value). We found that 9 source records appear to have not been included in the index, but upon further research found the nodes with duplicate keys. We created an F-pointer to the index file itself (not normally recommended, but useful), then got the results like the following: LIST indexfile WITH @ID = 12345] F1 F2 fname. F1 F2 12345 987654 876543 12345-6789 765432 543219 12345 654321 We are having our UniVerse administrator ask our dealer for assistance, but were interested if any other users have had any recent similar experiences, or advice. Sincerely Best Regards, Richard Lewis IBM Certified Solutions Expert Nu Skin Enterprises ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
