Hmmm. It's a very curious situation. Your data doesn't appear to be anything out of the ordinary (though it's neat about your munging).

Have you tried using the blook utility to scan through the btree file to see if anything is out of the ordinary? From the OS level, just issue blook without any parameters to get its syntax and options:

Usage: blook [options] file
       +a address     display nodes from addr to end
       -a address     display node at addr
       -d             display record keys and data
       -k             display record keys
       -i keylist     display item "key" only
       -n             disable auto pagination
       -r             traverse descending (default ascending)
       -s             generate statistics
       -v             verify file integrity: no details
       -V             verify file integrity: detailed report

       Environment variable interaction:
              LINES to control display depth
              COLS  to control display width

You might want to direct the output to a file then peruse it with your fav editor. I wrote this utility when I was implementing the secondary index files. Maybe you might be able to figure out what the heck is causing your troubles, pay close attention to see if maybe your inserted data might fall at the boundary of a node and a split is aborting. Let me know if you need any help in making heads or tails of anything.

At 03:39 PM 02/18/2004, you wrote:
-----Original Message-----
On Behalf Of Glenn Herbert
Sent: Wednesday, February 18, 2004 12:06 PM
Subject: RE: UV write fatal error

So what exactly is the particular data item that is causing the grief?


I am storing IP address information. My record ID is of the form 3232222208*3232223231. This ID is two numeric values that represent the IP address as a sequential integer (first octet multiplied by 2^24, second multiplied by 2^16, etc. then summed, then left-filled with zeros to a width of 10). The second numeric is the same if it is a single address. If it is a range of addresses, the first value is the beginning of the range and the second the end of the range. I convert the address being stored into the above form and do the BSCAN in descending order on the IP file looking for a match or an adjacent record (determined by additional code) that overlaps the record being stored. This process has worked flawlessly for all but a handful of records being stored, including the example above (3232222208*3232223231, which is 192.167.204-207, by the way). An example of the data this record structure would contain is as follows:


1>      1*69171
4>      192.167.204-207

I work for a publishing company and the IP addresses belong to our
customers for our web-accessed databases.

Thanks in advance for your consideration.


u2-users mailing list

-- u2-users mailing list [EMAIL PROTECTED]

Reply via email to