Problem with index 1

[mkendi]

In a table I have a character field with binary information (6 char) and a index for this field.
LOCATE finds the searched record, but SEEK returns always TRUE but stays in the first record.
The field is created as <char (binary)>.

I am using VFP6 SP5.

 

[foxbldr]

What's your index expression?

example: Index on <........>

Foxbldr

 

[mkendi]

INDEX ON kartno TAG kartno_idx

 

[craigber]

What are the LOCATE and SEEK expressions? If the value you are finding is stored in a variable, what is it's value? If character, is it PADed?

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports&quot;

 

[dbMark]

What does your seek expression look like? The command INDEXSEEK(seekstring) does what you are describing. It is a special variation of the SEEK command and SEEK() function where to tell it whether to move to the found record or not.

SEEK and SEEK() either move the record pointer to the matching record or if not found then to EOF(), end of file.

INDEXSEEK() has a second argument which by default is .F. so that it never moves the record pointer. If .T. then the record pointer moves only if a match is found.

If you're not using INDEXSEEK(), have you tried deleting the index or tag, then recreating it? If the SEEK works afterwards then maybe the index was corrupted.

 

[Docpro777]

As per Mark, indexseek() 2 times:
First time set it to .F., i.e., to prevent EOF() errors.

if INDEXSEEK(eExpression ,.F.) &&(=.T.)
=INDEXSEEK(eExpression ,.T.)
endif

Philip

 

[mkendi]

Sorry, also INDEXSEEK does not work.
My SEEK expression is
=SEEK(cTxt, &quot;Personal&quot;, &quot;KartNo_IDX&quot
cTxt contains (in Hex) 0x00, 0x00, 0x00, 0x03, 0x05, 0x08 and this value exists in table &quot;personal&quot;.
If I use the expression:
LOCATE FOR KartNo == cTxt
then everything works fine.

?

 

[craigsboyd]

mkendi,

As I understand it you are getting a match on the =SEEK(cTxt, &quot;Personal&quot;, &quot;KartNo_IDX&quot and it happens to be the first record in the table - this was not what you expected, since the Locate returns the first match as a totally different record (presumably the one you want). I noticed in looking at your code that you are using == with your locate so that it exactly matches, so my suggestion is try this:

SET EXACT ON
=SEEK(cTxt, &quot;Personal&quot;, &quot;KartNo_IDX&quot


...assuming that your index is correct for this seek this will cause the SEEK to look for an exact match similar to what you are using in locate statement.

Slighthaze = NULL

 

[mkendi]

I allways use SET EXACT ON.
And my index is not corrupted (only 3 entries, and rebuilded a few times)
But with SEEK I allways get TRUE returned (alltrough when I searche a record, which is not within the table) and the pointer stays allways on the first record.

 

[tesar]

mkendi,
try
SET NEAR OFF
sele personal
set orde to kartno_idx
=seek(ctxt)
* same result ?
Tesar

 

[mkendi]

Yes, unfortunately the same result ... (

 

[craigber]

Have you tried recreating the Index with INDEX ON?

I've seen this behavior when the index is corrupt.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports&quot;

 

[mkendi]

yes, of course

 

[AirCon]

I tried to create your problem (I think some people here already tried also). The result is, both SEEK and INDEXSEEK works correctly. But in your case it doesn't work.

Since you said it's only 3 entries, why don't you list what is the field value inside your table and what is the code (where the problem is) to search. Maybe we can figure out what is wrong

-- AirCon --

 

[mkendi]

Did you realy put binary values into the char field?
Of course all my SEEK operations works correctly: I have only problems with them, wich contains binary values.
So may I ask again: did you try it with binary values, e.g.
cTxt = CHR(0) + CHR(0) + CHR(0) + CHR(3) + CHR(5) + CHR(8)

 

[AirCon]

This is what I did.
- Create a table with character binary field (6 char)
- index on the field
- cTxt0 = CHR(0)+CHR(0)+CHR(0)+CHR(3)+CHR(5)+CHR(8)
- cTxt1 = CHR(1)+CHR(0)+CHR(0)+CHR(3)+CHR(5)+CHR(8)
- insert into &quot;table&quot; values (cTxt0)
- insert into &quot;table&quot; values (cTxt1)
- ?seek(cTxt0), recno() && result: .T. , 1
- ?seek(cTxt1), recno() && result: .T. , 2

It works correctly

-- AirCon --

 

[mkendi]

I'am going to cry. I did the same as you (copy & past). Same result as before: I get allways TRUE as seek-result but the record-pointer stays in first position.
Should I reinstall vfp? But why everything works correctly and only in this special case the &quot;bug&quot; becomes alive?

 

[dbMark]

When you said you rebuilt the index, did you REINDEX or did you actually delete the tags, and re-create the index? It is certainly possible that simply REINDEXing isn't enough to wipe out the index corruption.

With the table open you can type DISPLAY STATUS to view table and the details of its index. Is it correct?

Alternatively, with so few records, you could make a new table and new index and see if you still have the problem.

 

[mkendi]

Yes, I made both of them: REINDEX and delete the tags. And, of course, I created a new Table with only this single field. In all cases the same result.
I use codepage 1254 (turkish). Can this be the problem? Otherwise CHAR (binary) should made no translation.

 

[mkendi]

Uff! I found a small light in the darkness. If I create a table with codepage 1252, than the seek operation runs as desired.
Whats now? I have to work with codepage 1254 ...