 | |
#31
 
| |||
| |||
|
Re: D3 Indices -
08-07-2006
, 01:28 AM
|
I accepted the problems with REF as I was told that they were related to UPDATE which I was told was being tossed. |
remember an e-mail which essentially dismissed a UP change request
with the closing remark "the Update Processor is doomed". To this day
however, the core features of UP are still well supported - minus the
issue with indexes in the D3NT FSI. The problem with killing off UP
was/is that the internal applications used by RD themselves are
entirely dependent on UP, and killing it off wasn't in their own best
interest. Since they run over D3Linux the FSI index was never a
priority for them - I consider that prioritization to be a matter of
poor judgement. The day RD gets themselves some new apps is the day
we'll probably start seeing bugs creep into the more esotheric
features of UP.
#32
| |||
| |||
|
|
Perhaps simply more people like Peter that actually just need indices to work as advertised in ANY supported environment Jeff Caspari wrote: never did like the FSI, and at least 7.5 will allow 4Gb for VME Is that increase intended to promote production accounts in the VME or allow for reduced VME restores from leakage? |
#33
| |||
| |||
|
|
Ross, for your 20k item size test, I would be very interested to know what happens if you increase the frame size of your FSI file to 128k. Also check the memory consumption and flush rate for D3NT. You might get better results if you decrease the flush rate (I don't remember how to do this off-hand) |
Regards,
Bruce Nichol
Talon Computer Services
ALBURY NSW Australia
http://www.taloncs.com.au
If it ain't broke, fix it until it is....
#34
| |||
| |||
|
|
"Peter McMurray" wrote: I accepted the problems with REF as I was told that they were related to UPDATE which I was told was being tossed. In an exchange with Pick Systems Engineering about 8 years ago I remember an e-mail which essentially dismissed a UP change request with the closing remark "the Update Processor is doomed". To this day however, the core features of UP are still well supported - minus the issue with indexes in the D3NT FSI. The problem with killing off UP was/is that the internal applications used by RD themselves are entirely dependent on UP, and killing it off wasn't in their own best interest. Since they run over D3Linux the FSI index was never a priority for them - I consider that prioritization to be a matter of poor judgement. The day RD gets themselves some new apps is the day we'll probably start seeing bugs creep into the more esotheric features of UP. |
#35
| |||
| |||
|
|
The day RD gets themselves some new apps is the day we'll probably start seeing bugs creep into the more esotheric features of UP. |
some bugs get fixed.
Mark
#36
| |||
| |||
|
|
Good question Jeff - if we're discouraged from using it, why expand it? More space for hold files maybe? Sometimes when someone is coming from a different system they want to restore-accounts or do some other mass operation into the VME, then move stuff over to the FSI later. There are some sites that insist on working in the VME because of ongoing issues with the FSI (perceived or real). |
days. Given the size and cost of disks, most people can spare that 4GB
without blinking, so why keep the limit so low?
IMO they should have take it even further, but I guess there are
internal architectural reasons to do with the size of pointer registers.
Luke
#37
| |||
| |||
|
|
Hi Dale The major problem is not the value mark. The problem is that indices that work in the vme don't work in the fsi. Mark showed a way around the vm issue. As a result a second problem has been exposed, that is that valid A correlatives produced as per the instructions in the manual do not work with indices. By the way I have never used your value mark trick for copying it sounds too dodgy for me, I just follow the prompts. Peter McMurray "Dale" <benedictknowspam (AT) silk (DOT) net> wrote in message news:12d89s8abdd1819 (AT) corp (DOT) supernews.com... 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 (AT) bigpond (DOT) com> wrote in message news:OsVAg.6933$rP1.2942 (AT) news-server (DOT) bigpond.net.au... 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 (AT) drexelmgt (DOT) com> wrote in message news:A7hAg.13859$%a1.10121 (AT) tornado (DOT) socal.rr.com... 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 (AT) drexelmgt (DOT) com> wrote in message news:v60Ag.8218$Vq1.4667 (AT) tornado (DOT) socal.rr.com... "Peter McMurray" <excalibur21 (AT) bigpond (DOT) com> wrote in message news:4sZzg.5215$rP1.4602 (AT) news-server (DOT) bigpond.net.au... 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 |
#38
| |||
| |||
|
|
Hi Tony I asked initially to make sure I was on the right tram and got an excellent response from Mark. I am testing it because I am looking to do a demo to a major client in a fortnight and wanted to cover all the bases. I am now very glad that I have rolled my own for all these years even if it is a little more work. I am disgusted that I am finding such a mess when the product has been out for years. I first raised the lack of a proper test suite at Pick systems back around 1992. It seems that things have not improved, unfortunately I know they are not alone when I see some of the things that get released by other organisations. Far too many (Bill Gates included) seem to think that testers are an unecessary expense. I believe that after 30 years of ardently supporting Pick I can expect a prompt response to a posted query. I am not asking for additional functionality, I am asking for documented features to run properly, particularly as I am not pushing the envelope. Just for the record a simple name index on the address file in the fsi setup as per the example in the manual dumps everything into a null index - ie does not work even though it thinks it has . I will continue to do the testing but reiterate this is not beta testing, this is testing of standard methods. TData do a great job but I think that you would agree that I should not mess them about with queries until I know I am doing it right. By the way I enjoy your input to CDP. Peter McMurray "Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote in message news:f7gad25pur62525l23allk9aruong48f7p (AT) 4ax (DOT) com... (more weekend chatter) "Excalibur" wrote: Hi Ross I have lodged it initially on the support site with no answer. I lodged it here because it must ( and does ) affect everyone and I could have simply misunderstood the issue. I haven't as it turns out. I sometimes ask questions in forums (particularly the RD forum) as a community service as well, hoping someone with a clue will respond in public so that we all benefit. If the response doesn't come I'll send the stock form to support@ stormydata.com (not real address of course) and I almost always get a complete and courteous response. If I need clarification I initiate another round and inquiries are usually resolved within a couple days. The resolution can be "we're looking into it" or "yes, it's a bug, here's the action item number" or "it's not a bug but we've filed an action item for an enhancement or documentation update", or sometimes "Tony, you should know better". Once again I'm saying there is a process and it usually works. For this particular issue I think it's a shame that people are just finding out about something like this within days after a new release went production, especially when this one has been in beta (technically) for about five years. If certain features are important to you, sign up for betas (no matter what software we're talking about) - that's the time to file your requests and the time when these companies are most likely to make the changes you want. FWIW, I think RD did make a number of changes to index handling. Anything they didn't do probably wasn't established as a priority in the field. It's possible, but I don't think so, that the behaviour you're expecting here has changed in v7.5. As of yesterday I loaded 7.5 at enormous expense because it is not zipped - how many times do we have to tell people that many parts of Australia only have fraudband. That's been an issue at RD for years, especially since they intentionally throttle download bandwidth in order to keep their other business activity from getting interrupted. (I just downloaded the production v7.5 form their FTP site which is about 2 miles from here, and got a max speed of 174k/s. I downloaded another binary from my own FTP site which is hosted further away and got an average of over 880k/s.) I highly recommend you aussies ask TData to mirror the RD FTP site to make getting your software easier. For similar and additional reasons I allow our clients and prospects to download mv.NET and DesignBais (and related presentations, demos, marketing material, etc) from our website. I will be loading it on Monday when support is available if it barfs as has happened in the past. I see that it cannot be fully loaded without internet connection according to the readme. I will then prepare test accounts for submission to TDATA. This costs me time and money. Sorry, but if this was a concern to you, you should have asked TData to check it for you a month ago when they were running the beta. Why is this a priority all of a sudden that's being approached with so much indignation? I think I understand that you're just testing what should be working functionality. Fair enough. If it doesn't work, file an action item and see if they fix it. Until then it's not like you were relying on this for a live site anyway. However I should not have to do this, and it is obvious that other people have just worked around the problems. That is not good. Please remember that many of us cannot just ask the person in the next cubicle. Regards Peter McMurray I agree that you shouldn't have to go through a lot here but this is why people have Value-Add Resellers: Ask your VAR (TData?) if the functionality you want is in v7.5. TData people read this forum, so before you go through extra work, just call them and ask them if they can take the info you've already posted here, do a test, and file a report with RD if it doesn't work. Good luck. T |
#39
| |||
| |||
|
|
For those having issues with D3 indexes in the FSI, it may be advantageous to review your "common" use in BASIC (especially "named common"). I've always had problems with FSI indexes when using BASIC programs with "common", and when using anything but simple "A" correlatives. So, I would start there to fix the problems (along with reporting them to RD). A few of our clients have not had any problems with UniData indexing so far (knock on wood). :-) |
large b-trees in the FSI, and no problems. I'm frustrated by the lack of
support in Access (range queries etc), but nothing actually fails.
Luke
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.