0.60 and VARYING Length Strings

Testing has revealed that Release 0.60 has some issues with
indexes, primary and secondary where strings are variable
in length. This problem has been fixed in cvs and will
be part of the next release.

However, for current release 0.60 users, you can still
get your present apps to work if you use fixed length
strings in place of any VARYING length strings. This
applies to all database content, whether or not it
participates in an index. All other data types currently
supported are ok.

The problem was that the field offsets for each column's
value were fixed at record definition time. However, the variable
length column data causes the offsets of the following
fields to move, and making the data transfers unreliable.
This might even crash the interpreter, though the author
never experienced this.

The current development has revised the handling of variable
length data in both the database record and the index(es).
The VL strings were previously padded out to their maximum length
with blanks. But this leads to sparse index blocks causing
poorer performance and obviously poor disk utilization.

For VARYING strings, the length is now stored in 1 to 5 bytes,
depending upon string's length, followed only by the string
content. An empty string now only requires one byte, indicating
a length of zero. For string lengths up to 127, only one
length byte is required to prefix the string data.

Look for these improvements and more, in the upcoming 0.70
release.