Re: D3 Indices
- From: "Dale" <benedictknowspam@xxxxxxxx>
- Date: Fri, 4 Aug 2006 22:07:17 -0700
The value mark is the rub in this instance!!!
I don't know about the Windows version of D3 but in Linux you can have a
multi-line TCL statement and each statement is separated by the value mark.
I quite often copy data from on file to another using:
copy firstfile VM (second file
The allows me the ability to us the Update Processor ( I know ya don't like
the update processor :^P ) to ensure that I get all my typing correct before
commiting the statement(s) for processing.
I guess the advice here is to stay away from value marks in indexes.
Although you can punch the index into the ADI and then at TCL enter the
statement: create-index filename *
See TFM for better instructions.
Hope this helps,
Dale
"Peter McMurray" <excalibur21@xxxxxxxxxxx> wrote in message
news:OsVAg.6933$rP1.2942@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Mark
Just out of cussedness I suppose. I created a VME account and dropped the
same files and dictionaries in. You are quite correct of course your
variation worked as an Index and mine failed with a more expressive error
message about missing right parens as it chipped off at the value mark. A
basic program showed the correct results in the index unlike the FSI that
put them all into 000 However mine worked as a SORT BY-DSND "052]" and
yours did not, it just returned everything, at least it was correctly
sorted.
It seems that there is a major SNAFU. I cannot for the life of me see why
there are two independent interpretations of an algebraic correlative with
both returning different results. Surely to goodness they should both be
using the same base code. Given recent discussions about objects I can
see a few others being a bit surprised.
I look forward to an explanation from RD. I put it on the support board
but have had no response which is disappointing. I shall have a look at a
couple of other variations to see how far this goes.
Peter McMurray
"Mark Brown" <mbrown@xxxxxxxxxxxxx> wrote in message
news:A7hAg.13859$%a1.10121@xxxxxxxxxxxxxxxxxxxxxxx
I appologize. When I saw your original post, I immediately jumped into my
"test" account, created a file, dict items and data and tried everything,
and, of course, it works perfectly.
However, when I saw another of your posts where you say it does, and as I
don't think you'd lie about it, I went back and to my shagrin, I find
that my test account is a VME account where indexing actually works.
The problem is the NT FSI specific indexing. I easily reproduced your
problem and you're absolutely right: that one just doesn't work.
I still have a couple friends, so I'll send them a "reproducable case".
Since they seem hell bent to move FSI into the *nix product line, this is
something that has to be fixed.
Since FSI file system is different, the index is also different. I know
the people involved in creating it and I won't say a bad word about them,
but this is one place where they really let us down.
As to a-correlatives, I came to them late in life, too; but now I love
them. Since you can basically stack stuff forever, you can make dict
items like this (short examples; but you'll get the idea):
a0:N(CO)(R%2) : N(PRODUCT)(R%6) : N(PACK)(R%8)
At least, you only need to do it once and you could probably actually
create a little Pick Basic routine to prompt for that stuff and build a
new dict item for you. That's what I'd do.
Your "key" data is only 50 bytes long and, with all that, I'd assume
probably pretty unique. But you would probably be just as well served
with some kind of a file-time trigger to update cross-reference file with
this data, with the key as the "key" then a simple index on a0. So
something like this would work:
select stkmve.xref with a0 "something*meaningful"
select stkmve.xref a1
first select gets the keys that match and the second returns all ids
Mark
Here are some examples. The first two are on the stock movement file
and all the information is contained within the stock movement record.
Enquiries cannot wait for a full sort of the file. An algebraic
dictionary is going to be a mess. More importantly the second will only
exist for Stock Purchases and Returns.
STKMVEBT1*1
001 Stock Movements By Product & Pack - Btree
002
003 STKMVEBT1F
004 KEY
005 CO "R%2"
006 PRODUCT "R%6"
007 PACK "R%8"
008 DEPOT "L#4"
009 LOCCODE "L#4"
010 PERNO "R%7"
011 MVETYPE "R%2"
012 MVEDAT "R%5"
013 SOURCECO "R%2"
014 BATCHNO "R%6"
015 BLINE "R%3"
016 BATCHTYPE "L#1"
:
STKMVEBT2*1
001 Stock Movements From Suppliers - Btree
002
003 STKMVEBT2F
004 KEY
005 MVESOURCE "L#8"
006 MVEDOC "R%8"
007 SOURCECO "R%2"
008 DEPOT "L#4"
009 BATCHNO "R%6"
010 BLINE "R%2"
:
This combines Name information from the Debtors master file, which
controls credit, with Address information from the Address file which
controls pricing and delivery information. The Aboriginal centre may
have deliveries to 40 or 50 settlements, the Seventh Day Adventists may
have deliveries to a dozen of their pastors, ColesMyer could have 700 to
800 delivery points.
NAMEBT*1
001 The Name Enquiry Btree File
002
003 NAMEBTF
004 KEY
005 SORTNAME "L#10"
006 CO "R%2"
007 NUMBER "R%6"
008 ADDNO "R%3"
This allows us to check delivery requests by street. Dodgy debtors
often come in with different names but the same delivery address - it is
not much good having your heating oil delivered to somone else's tank.
STREETBT*1
001 The Street Enquiry Btree File
002
003 STREETBTF
004 KEY
005 SORTSTREET "L#10"
006 ADDNUM "R%5"
007 CO "R%2"
008 NUMBER "R%6"
009 ADDNO "R%3"
:
"Mark Brown" <mbrown@xxxxxxxxxxxxx> wrote in message
news:v60Ag.8218$Vq1.4667@xxxxxxxxxxxxxxxxxxxxxxx
"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)
I've been working on B-trees sinced they were still called balanced
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
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
.
- Follow-Ups:
- Re: D3 Indices
- From: Excalibur
- Re: D3 Indices
- References:
- D3 Indices
- From: Peter McMurray
- Re: D3 Indices
- From: Mark Brown
- Re: D3 Indices
- From: Peter McMurray
- Re: D3 Indices
- From: Mark Brown
- Re: D3 Indices
- From: Peter McMurray
- Re: D3 Indices
- From: Mark Brown
- Re: D3 Indices
- From: Peter McMurray
- D3 Indices
- Prev by Date: Re: D3 Indices
- Next by Date: Synonym for last multivalue
- Previous by thread: Re: D3 Indices
- Next by thread: Re: D3 Indices
- Index(es):
Relevant Pages
|