Hi Emanuele ( ciao ),

The problem is a global problem.

If you use REINDEX, Moving index definition it does not prevent the situation:

**-------------------------------------------------
Create Cursor test(CodeTest char(5), Num I NULL)

Index On (CodeTest + BinToC(Num)) tag Num

Insert into test(CodeTest, Num) values ('Code1', 1)
Insert into test(CodeTest, Num) values ('Code1', 0)
cSeekExpr = CodeTest + BinToC(Num) && I want found this record, i retrive the index key!
Insert into test(CodeTest, Num) values ('Code2', 0) && Removing this line the problem doesn't exists

REINDEX
*Index On (CodeTest + BinToC(Num)) tag Num && Moving this line after Create cursor the problem doesn't exists
** The actual Tag is "Num"
** So i expect that following sequence for the first 2 records 
** Codetest Num
** ------------------
** Code1 0
** Code1 1
**
** But the order is
** Codetest Num
** ------------------
** Code1 1
** Code1 0
** The index was not created properly!!
GO TOP 
ACTIVATE SCREEN
clear
? 'Actual Key: ' + KEY()
? 'Codetest Num'


** cSeekExpr is the key retrvieved from second record inserted
?
? 'Searching for: "Code1" + BINTOC(0)'
? 'Found() = ', KEYMATCH(cSeekExpr),SEEK(cSeekExpr)

USE in test

The problem is not related to the BINTOC() function or nullable field,
but with any index for strings concat and B-TREE build/seek routines.

I search a general condition, this can to be incomplete, but see a trace of the problem

**-------------------------------------------------

*the bug is present
h = 3   	&& for any n 1..238 
n = 128	        && for any n 0..255 
x = 255	        && for any x 1..255
a1 = CHR(0) && for any a1 string 
a2 = CHR(1) && for any a2>a1

Create Cursor test(F1 C(MAX(LEN(a1),LEN(a2))), F2 C(m.h+1))

Index On F1 + F2 tag Num

Insert into test(F1,F2) values (m.a1, REPLICATE(CHR(m.n),m.h)+CHR(m.x))
Insert into test(F1,F2) values (m.a1, REPLICATE(CHR(m.n),m.h)+CHR(0))
cSeekExpr = F1 + F2
Insert into test(F1,F2) values (m.a2, REPLICATE(CHR(m.n),m.h)+CHR(0)) && Removing this line the problem doesn't exists

REINDEX

** cSeekExpr is the key retrvieved from second record inserted
?
? 'Searching for: "Code1" + BINTOC(0)',cSeekExpr
? 'Found() = ', KEYMATCH(cSeekExpr),SEEK(cSeekExpr)

LOCATE FOR F1+F2==cSeekExpr
? FOUND()
SELECT * from ALIAS() WHERE F1+F2==cSeekExpr
USE in test

BUT THIS OCCUR ONLY FOR CONCAT STRINGS ?

ATTENTION , NOOOOOOOOOOOOOO !!!!
With single field index the problem occur:

**-------------------------------------------------

*the bug is present
h = 3   	&& for any n 1..238 
n = 128 	&& for any n 0..255 
x = 255 	&& for any x 1..255
a1 = CHR(0)    && for any a1 string 
a2 = CHR(1)    && for any a2>a1

Create Cursor test(F1 C(MAX(LEN(a1),LEN(a2))+m.h+1))

Index On F1  tag Num

Insert into test(F1) values (m.a1+REPLICATE(CHR(m.n),m.h)+CHR(m.x))
Insert into test(F1) values (m.a1+REPLICATE(CHR(m.n),m.h)+CHR(0))
cSeekExpr = F1 
Insert into test(F1) values (m.a2+REPLICATE(CHR(m.n),m.h)+CHR(0)) && Removing this line the problem doesn't exists

REINDEX

** cSeekExpr is the key retrvieved from second record inserted
?
? 'Searching for: "Code1" + BINTOC(0)',cSeekExpr
? 'Found() = ', KEYMATCH(cSeekExpr),SEEK(cSeekExpr)

LOCATE FOR F1==cSeekExpr
? FOUND()
SELECT * from ALIAS() WHERE F1==cSeekExpr
USE in test

I have found a workaround, but before post it i test it.

Comment:

The problem is related with CHR(0) end of index key;
but this is related with a big ugly choice on C, to use Z-string.

The another true problem is this:
VFP use a routine for full REINDEX a index,
and uses another routine for INSERT/UPDATE/DELETE reindex ( you can see this when uses a filtered
index FOR ..., on this case eval order of index elements is different );
this is not a bug, but this is a ugly implementation, that it increases the bugs probability).

THIS PROBLEM OCCUR ON VFP6SP5, VFP7SP1, VFP8 and VFP8SP1 !

Question ? How is possible this ????

Today VFP have lost the index ?

Where is my error ? I want somebody found a my error, please !

Fabio


Fabio