I've just picked up some data in an old vpf 3.02b program, and on
running the routines, a reindex throws up the message:

"invalid key length"

The index key appears to be strtran(phone, " ") - designed to strip
spaces in a phone number.

The phone field is a character field, and this used to work!!

Can anyone tell me what 'invalid key length' is trying to communicate?
(And yes, I've searched the help index until I'm blue in the face.)

Thanks.

foxed,

Mike
[The reply-to address is valid for 30 days from this posting]
--
Michael J Davis
<><
Some newsgroup contributors appear to have confused
the meaning of "discussion" with "digression".
<><

Mike,
Keys are stored internally as a fixed length string, so the expression should always create them with a fixed length. Some versions of FoxPro are more picky than others. e.g. Instead of:
strtran(phone, " ")
try:
padr(strtran(phone, " "), 10)

You probably got the error when you did a reindex, and it found the first record was blank, which would cause it to be a zero length key - definitely an invalid length!

Rick

"Michael J Davis" <?.?@trustsof.demon.co.uk> wrote

Michael J Davis <?.?@trustsof.demon.co.uk> wrote:

Try "error messages" (from the VFP 6 on-line help):

"Invalid key length (Error 112)
Index keys must be between 1 and 240 characters.

You created an index key of length 0.
When Visual FoxPro creates an index, it evaluates fields in the first
record in the table. Make sure that the first record of the fields you
base the index on contains some data.

You created an index key longer than 240 characters.
Create a shorter index key."

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Rick - thanks!

That solved it, but I am still baffled.

I have used this method of indexing different layouts of phone numbers
for years in de-duping databases, and not had this problem before, *in
spite of* differing field lengths.

In this case the problem started when we introduced some records with no
phone nos. To avoid strtran(phone, " ") giving a null, we put '-' in the
phone field. The same problem recurred. So that's when I got confused.

Anyway - your right padding certainly has made the problem go away -
we'll have to use it elsewhere. Thanks.

Mike

Rick Bean <rgbean (AT) NOSPAMmelange-inc (DOT) com> opined
[The reply-to address is valid for 30 days from this posting]
--
Michael J Davis
http://www.trustsof.demon.co.uk
<><
For this is what the Lord has said to me,
"Go and post a Watchman and let
him report what he sees." Isa 21:6
<><

Gene Wirchenko <genew (AT) mail (DOT) ocis.net> opined
Gene

I am stupid enough to think that when I go to help and enter search, it
would actually find the 'error messages'. ;-(

Thanks - got it now. I'm using Rick's suggestion of r-padding to avoid
the issue.

I can only conclude that the '-' I used to show blank phone numbers was
regarded as a zero length (character) field when I indexed.

Certainly there was no problem about the first record containing data.
Not my problem - Thanks again!


Mike
[The reply-to address is valid for 30 days from this posting]
--
Michael J Davis
http://www.trustsof.demon.co.uk
<><
For this is what the Lord has said to me,
"Go and post a Watchman and let
him report what he sees." Isa 21:6
<><

Michael J Davis <miked (AT) trustsof (DOT) demon.co.uk> wrote:

Let me help you with those baffles.

Exactly.

Not a null, but "". They are two different things. .null. is
the absence of a value. "" is a string value of length zero.

I do not see how the "-" could have still resulted in a "" key.
Maybe, you missed some?

The Explanation

What should VFP do when generating values into a fixed-length
when the values can vary in length?

What it does is figure the length according to the first item and
use that length for all the rest.

In your case, the first strtran(phone," ") was "". That is
length 0. Indexes are keyed by 1 to 240 bytes. BOOM!

This can happen with computed columns in SQL. Try this contrived
example:
create table t (a n(3))
insert into t (a) values (1)
insert into t (a) values (123)
select iif(a#1,a,0) from t
select iif(a#1,a,000) from t
The first select determines the width of the column from the first
value (0). This means that the second value (123) will not fit. The
second select has extra zeroes in the constant to make the width
correct. (Yes, VFP looks at this.)

Yes, because it can bite elsewhere.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Michael J Davis <miked (AT) trustsof (DOT) demon.co.uk> wrote:

[snip]

That is not stupidity, but ignorance. Feel better? <EG>

Oh, it will, along with everything else. You see, son,...

Search looks for each of the words separately which is rarely
what you want. Instead of finding the message, it will KILL KILL KILL
MUST KILL IDIOTS WHO WROTE SEARCH find the occurrences of the
keywords.

What you should do, aside from wondering why Microsoft does not
think that programmers can be trusted to handle the logic of boolean
search elements, is
Select Index tab.
Enter "error messages".
Select the listing you want: numeric or alphabetical.
Navigate to the message.

Or lpad() or pad() or any other way of generating a fixed-length
string.

Nope.

If there was one phone number you missed and it was the first
value, you would still have the problem.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Gene Wirchenko <genew (AT) mail (DOT) ocis.net> opined
Thanks!

No - I checked! That's partly why I was surprised at the error message.
(and why I wondered what it meant!)

Certain the first one wasn't - I manually entered the "-"!!
Thanks, Gene - a lesson well explained.

Mike
[The reply-to address is valid for 30 days from this posting]
--
Michael J Davis
http://www.trustsof.demon.co.uk
<><
For this is what the Lord has said to me,
"Go and post a Watchman and let
him report what he sees." Isa 21:6
<><