Re: D3 Indices


"Peter McMurray" <excalibur21@xxxxxxxxxxx> wrote in message
news:4sZzg.5215$rP1.4602@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Mark
Thanks for the rapid response ( DO you work all night?) Unfortunately the
suggested correlative does not work in SORT BY-EXP as my original did.
Nor does the new method bring back a sorted list with say SORT INVOICES
BY-EXP GRPDESC "052]" it just comes back with no items present. In
trying to look at the key I could be wrong with my code but using the 'N'
option to race through all the keys it appears to have just made a list of
all the invoice lines unsorted.

Here's my test file. Only three records and not much data

:list test pd
Page 1 test
04:20:56 02 Aug 2006

test...... Prod Desc.....................

2 003product 3
3 001product 1
003product 3
1 002product 2
001product 1

[405] 3 items listed out of 3 items.
:sort test pd by pd
Page 1 test
04:21:18 02 Aug 2006

test...... Prod Desc.....................

3 001product 1
003product 3
1 002product 2
001product 1
2 003product 3

[4051] 3 items listed.
:sort test pd by-exp pd
Page 1 test
04:21:22 02 Aug 2006

test...... Prod Desc.....................

1 001product 1
3 001product 1
1 002product 2
2 003product 3
3 003product 3

[4051] 5 items listed.

My a-corellative was

a1(TPROD;X;3;3)(MR%3):1(TPROD;X;2;2)

I'm running 7.4.4.400


If I take into account the enormously messy way I have to actually
reproduce the English correlative in Basic and I would typically have upto
9 or 10 attributes in a btree key. I am wondering if it is worthwhile on
anything but the most simplistic sorts.

I'd like to see something like that. Usually I find we tend to
over-complicate things.

By the way I meant no disrespect to you. In fact I have fond memories of
the best presentation ever given over a couple of days was yours on
Microsoft interfacing. I don't remember who it was that answered my
original query but they certainly avoided complex keys that I specifically
asked about. I certainly have a better understanding of what Pick is
doing now from your post and it is not what I was expecting. Perhaps you
could volunteer a complex English correlative that I could work through

Don't worry (be happy). I get plenty of disrespect, so I never feel short
changed.

How about: aa (correl: tprod;x;3;3) and bb (tprod;x;2;2) and then you can

an(aa)(mr%3):n(bb)


As for Btrees I have been using them for nigh on 25 years as Micromax had
a brilliant implementation and I sold the first of the Micromax 3000's of
the convention floor in 1982. The B-trees worked so well the client ran
around telling everybody how his new system was 10 times faster than his
direct IBM mainframe link to BP with the same data (we actually picked up
25,000 customers from the mainframe tapes so the data was very similar).

Regards
Peter McMurray

I've been working on B-trees sinced they were still called balanced trees,
when there were a fixed number of indexes per node and that was it. You
designed your tree with 1 block at the top, a second level with as many
blocks as there were keys in the first block, etc until you ended up with
the last layer which held one key:id pair for each record in the file.
Theoretically, it never took more than levels + 1 read to get to any record.

BTW, I use indexed a LOT in Visual Basic and DOT Net. It's much faster to
read an index, put the display key into a pull-down or listbox and store the
item id than to sselect the file and read every record to get the same
information.

Mark Brown


.