bad index?

[LenaS]

I have a file that I cannot seem to get the index right.
two fields: claim Numeric 7,0 and claimsub numeric 2,0
My expression is claim + claimsub and I call it claim9
this is what shows up on the browse


Claim Claimsub
3000011 0
3000010 1
3000010 1
3000010 1
3000011 0 etc,..

what is up?

 

[MitchUK]

Unsure, but are both fields numberic??

If so does this expression add the numbers together, or concatenate them as a string?

does converting them to a string work?

GOOD LUCK Have knowledge, lack patience. >:-<
MitchBsc@yahoo.co.uk

 

[LenaS]

Yes, as I stated, they are both numeric. Examples in HELP show this kind of expression exactly as I have created it. I tried deleting the index and recreating it. No good. Makes no sense to me.

 

[ChrisRChamberlain]

LenaS

Try

ALLT(STR(claim))+ALLT(STR(claimsub))

as the index expression

Chris

 

[MitchUK]

Just created a similar table, enabled data buffering, and used your expression.

Added rec's

3000011 0
3000010 5
3000011 0
3000012 2

then opened the work area properties and implemented the index.

browser now shows

3000011 0
3000011 0
3000012 2
3000010 5

Looking at this, this is adding them together rather than combining the two, maybe chris' way may be the right one (using them as strings as first suggested??) Have knowledge, lack patience. >:-<
MitchBsc@yahoo.co.uk

 

[q2eddie]

Hi, LenaS.

Awhile back, I found that fixed-length index expressions allow for faster SQL-Select statements than variable-length expressions. Also, if you have claimsubs above 9, then the &quot;ALLT(STR(claim))+ALLT(STR(claimsub))&quot; expression will cause the index to sort incorrectly.

For example:
3000011 1
3000011 2
3000011 10
3000011 11

... would become ...

3000011 1
3000011 10
3000011 11
3000011 2

Possible Fixed-Length Alternative:
1. bintoc(claim)+bintoc(claimsub)
2. str(claim,9,0)+str(claimsub,2,0)
(tran = transform)
3. tran(claim,&quot;999999999&quot+tran(claimsub,&quot;999999999&quot

Bye. -e2

 

[ChrisRChamberlain]

LenaS

Apologies - had only tested on your original data and q2eddie is correct.

Chris