Index corruption oddity on fp 5.0.14

[Bruce Easton]

I recently ran into an index corruption issue on a client site running
fp 5.0.14 on windows.

After running the debugger, I would see that two indexes built on a
field whose value changed just prior to using the copy [from_alias]
to [to_alias] command would get corrupted immediately after that
command.  After this corruption, in another program, a lookup loop
would find the record (whose value had changed, but sorted as if the
value had not changed).  I could find the record using clerk, but
when I would select it and then go back to the browse, it then
appeared like it was the only record in the file.  (By the way, the
field being changed is a simple 'last, first' name field, so I was
testing with values like 'Washington, Frank' and similar.)

I found that if I replaced:

      Then: copy fralias to toalias

with assignments in a loop using two arrays:

      Then: dim frarr(245):fralias(1)
        If:
      Then: dim toarr(245):toalias(1)
        If:
      Then: cn(3,.0)="1"
cnloop If: cn lt "246"
      Then: toarr[cn]=frarr[cn]; cn=cn+"1"; goto cnloop

that the problem disappeared.

This is a program that rclerk runs from @menu (outside of the file
opened as fralias and toalias), and has many lookups and writes out
a file via jsfile.  I should also note that above, the lookup
opened as fralias is a qualified data set of the file opened as
toalias. (tolias is the unqualified key.)  I made sure that lookups
to the 'fralias/toalias' file (and its qualifier) were closed before
and after this instance of copying data.  After closing these lookups,
the program terminates with a plain, unconditional 'close' and then
an exit command.

There are other instances of the 'copy .. to ..' command in this
program, and one against the same file and qualifiers (although in
the other case the main record is being copied to the qualified key),
but only this one instance resulted in an index corruption.  There is
no auto table in use for this program.  Everything happens in this
program from @menu until exit without reading/writing from/to the
control file that it runs from.

I only thing I see in release notes for 5.0.15 that looks like it
could be related is:

   (All) #927

   Fixed a problem with node_addr and DKNF errors on indexes which
   are larger than 65536 blocks in size.

The file sizes for the two indexes getting corrupted here are 1160KB
and 1376KB; the record length is 2650, and the shortest of the two
indexes is built on the full 26 length of one field.

I started to think this might only be a problem on windows fp, but
when I went into the same program on our development linux and unix
boxes, I saw where I had made a comment that previously, I had seen
index corruption from that one line there, but had trouble
reproducing (so it must have been inconsistent if not rare).  On
this windows server, the corruption from that one instance of that
one command has been consistent.


Bruce Easton








-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20111206/b60faa86/attachment.html