FUNNY Indexing

[avista]

Hi to all
This is example program:

#include "FiveWin.ch"
//----------------------------------------------------------------------------//
function Main()
local i := 0
local aData := {"11","9","9999999999","99999999999","11111111111" }
DbCreate( "MyDbf.dbf", { { "Field1", "C", 13, 0 } } )
USE MyDbf
FOR i = 1 TO LEN( aData)
DbAppend()
REPLACE Field1 WITH aData[ i ]
NEXT
INDEX ON VAL(MyDbf->Field1) TO MyIndex
XBROWSE()
return nil

DATA ARE ORDERED LIKE THIS:
99999999999
11111111111
9
11
9999999999


Best Regards

[Enrico Maria Giordano]

Code: Select all  Expand view

INDEX ON STR(VAL(MyDbf->Field1),LEN(MyDbf->Field1)) TO MyIndex

Please note:

1. This is standard Clipper behavior (I just tested with Clipper 5.3b).

2. This is not a problem with FWH.

EMG

[Rick Lipkin]

Avista

Code: Select all  Expand view

INDEX ON VAL(MyDbf->Field1) TO MyIndex
 

Try eliminating the database name in the index ..

Code: Select all  Expand view

Select MyDbf
INDEX ON VAL(Field1) TO MyIndex
 

Rick Lipkin

[Gale FORd]

The problem is the val() function does not return a fixed length and the index needs to be fixed length.
Like Enrico's example, you should convert it to a fixed length string.

[avista]

Hi,

INDEX ON STR(VAL(MyDbf->Field1),LEN(MyDbf->Field1)) TO MyIndex

Yes this is going well ....

Enrico ...this is problem in FWH too if you use NTX index ...with CDX there is no problem.

Thanks to all,
Best regards,

[MarcoBoschi]

avista
> this is problem in FWH too if you use NTX index ...with CDX there is no problem.
enrico
>1. This is standard Clipper behavior (I just tested with Clipper 5.3b).
It's standard but it's wrong and very dangerous!

bye

marco

[Enrico Maria Giordano]

I repeat: it's not a problem with FWH. Please report it to comp.lang.xharbour.

EMG

[hmpaquito]

Hi,

I never use numeric keys.
1st) In dates do not obtain good order; it's necessary dtos()
2st) Numerics do not permit add subkeys field1+ field2

I allways use character key expressions, are more controllables (length key) y expansives (subkeys)

Regards

[Enrico Maria Giordano]

I used dates as index key sometimes and never find any problems.

EMG

[hmpaquito]

emg,

dates aren't good keys

INDEX ON Date1 TO FileOrder // obtain wrong order:
...
23/01/2011
23/01/2012
23/01/2013
24/01/2011
24/01/2012
24/01/2013
...


INDEX on DToS(Date1) TO FileOrder // obtain right order:
...
2011/23/01
2011/24/01
2012/23/01
2012/24/01
2013/23/01
2013/24/01
...

Regards

[Enrico Maria Giordano]

Please post a complete sample showing the problem.

EMG

[hmpaquito]

I dont understand; there is no problem; i haven´t problem. I only say: date expression do not keep year+month+day natural order and consequently they are very bad order key.That's all.

[Enrico Maria Giordano]

But since I already used (as I said) dates as index key without any problems then I can't confirm the behavior you reported. So I need a sample showing that behavior. The following sample works fine for me:

Code: Select all  Expand view

#include "FiveWin.ch"
//----------------------------------------------------------------------------//
function Main()
local i := 0
local aData
SET DATE BRITISH
aData = {CTOD( "23/01/2011" ), CTOD( "24/01/2011" ), CTOD( "23/01/2012" ), CTOD( "24/01/2012" ), CTOD( "23/01/2013" ), CTOD( "24/01/2013" ) }
DbCreate( "MyDbf.dbf", { { "Field1", "D", 8, 0 } } )
USE MyDbf
FOR i = 1 TO LEN( aData)
DbAppend()
REPLACE Field1 WITH aData[ i ]
NEXT
INDEX ON MyDbf->Field1 TO MyIndex
XBROWSE()
return nil

EMG

[hmpaquito]

Enrico,

You are right. I was thinking in

INDEX ON DToC(Date1) TO TmpFile

DToC() function return bad order expression key

INDEX ON Date1 TO TmpFile is ok; my fault; I´m sorry


Regards

[Enrico Maria Giordano]

No problem at all, my friend.

EMG