<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>I recently ran into an index corruption issue on a client site
running <br>
fp 5.0.14 on windows.<br>
<br>
After running the debugger, I would see that two indexes built on
a <br>
field whose value changed just prior to using the copy
[from_alias] <br>
to [to_alias] command would get corrupted immediately after that <br>
command. After this corruption, in another program, a lookup loop
<br>
would find the record (whose value had changed, but sorted as if
the <br>
value had not changed). I could find the record using clerk, but
<br>
when I would select it and then go back to the browse, it then <br>
appeared like it was the only record in the file. (By the way,
the <br>
field being changed is a simple 'last, first' name field, so I was
<br>
testing with values like 'Washington, Frank' and similar.)<br>
<br>
I found that if I replaced:<br>
<br>
Then: copy fralias to toalias<br>
<br>
with assignments in a loop using two arrays:<br>
<br>
Then: dim frarr(245):fralias(1)<br>
If:<br>
Then: dim toarr(245):toalias(1)<br>
If:<br>
Then: cn(3,.0)="1"<br>
cnloop If: cn lt "246"<br>
Then: toarr[cn]=frarr[cn]; cn=cn+"1"; goto cnloop<br>
<br>
that the problem disappeared.<br>
<br>
This is a program that rclerk runs from @menu (outside of the file
<br>
opened as fralias and toalias), and has many lookups and writes
out <br>
a file via jsfile. I should also note that above, the lookup <br>
opened as fralias is a qualified data set of the file opened as <br>
toalias. (tolias is the unqualified key.) I made sure that
lookups <br>
to the 'fralias/toalias' file (and its qualifier) were closed
before <br>
and after this instance of copying data. After closing these
lookups, <br>
the program terminates with a plain, unconditional 'close' and
then <br>
an exit command.<br>
<br>
There are other instances of the 'copy .. to ..' command in this <br>
program, and one against the same file and qualifiers (although in
<br>
the other case the main record is being copied to the qualified
key), <br>
but only this one instance resulted in an index corruption. There
is <br>
no auto table in use for this program. Everything happens in this
<br>
program from @menu until exit without reading/writing from/to the
<br>
control file that it runs from.<br>
<br>
I only thing I see in release notes for 5.0.15 that looks like it
<br>
could be related is:<br>
</tt>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<p><tt> (All) #927</tt></p>
<tt> </tt>
<p><tt> Fixed a problem with node_addr and DKNF errors on indexes
which <br>
are larger than 65536 blocks in size.<br>
</tt></p>
<p><tt>The file sizes for the two indexes getting corrupted here are
1160KB <br>
and 1376KB; the record length is 2650, and the shortest of the
two <br>
indexes is built on the full 26 length of one field.<br>
</tt></p>
<p><tt>I started to think this might only be a problem on windows
fp, but <br>
when I went into the same program on our development linux and
unix <br>
boxes, I saw where I had made a comment that previously, I had
seen <br>
index corruption from that one line there, but had trouble <br>
reproducing (so it must have been inconsistent if not rare). On
<br>
this windows server, the corruption from that one instance of
that <br>
one command has been consistent.<br>
</tt></p>
<p><tt><br>
Bruce Easton<br>
</tt></p>
<p><tt><br>
</tt></p>
<p><tt><br>
</tt></p>
<p><tt><br>
</tt></p>
<tt><br>
<br>
<br>
<br>
</tt>
</body>
</html>