RE: Spam:RE: [U2] Index Problem
From: Brenda Price 1. snip only necessary to rebuild the index(es) when you have a known corruption issue. snip Management decision from a long time ago and it is our comfort level to continue. I agree in principal with not rebuilding, but do not have 100% faith in any technology providing 100% reliability. 99.9% is sometimes not good enough. When clients are relying on us to provide their financials via web reports on a timely and accurate basis that .1% could lose us a big client and lots of money if it was wrong. Rather than rebuilding them, I would encourage you to just verify they are ok. Here's a way with no impact on your production system: Restore the file and its indexes TO your dev/test system FROM your standard backup (I assume you back up when the db is quiet!) Be sure to use SET.INDEX to correct the path. Then compare what's in the index with what should be in the index. I have a routine that does that, but I think a better way would be to --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index Problem
I have not seen a problem since about UV9.6. 4 corrections to my own claim. There are 3 common sources of index corruption, all user-related: 1. Indexing a computed value, whose calculation does not depend ENTIRELY on the record being written. E.g.: - trans(), xlate(), T-correlatives - date(), time() - @variables such as @logname, @date, @who - SUBR(), where the subroutine READs anything. 2. Copying the primary data file using OS-level or Non-UV-aware utilities, but not correcting the file header's pointer to production index files. Updates to the copy will be indexed on the primary! Use SET.INDEX INFORM SET.INDEX TO NULL on the _copy_ of the data file. 3. Updating the index files explicitly. Usually happens when there is a voc pointer to the .../I_fname/INDEXnnn type-25 file. There is a 4th that I consider it a long-standing bug. It is known to IBM. And to Informix, Ardent, Vmark before them. 4. CNAME will not update any index on part of an id, e.g., FIELD( @ID, '*', 1 ). I was told CNAME uses an i/o mechanism different from every other update. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index Problem
I have not seen a problem since about UV9.6. 4 corrections to my own claim. There are 3 common sources of index corruption, all user-related: 1. Indexing a computed value, whose calculation does not depend ENTIRELY on the record being written. E.g.: - trans(), xlate(), T-correlatives - date(), time() - @variables such as @logname, @date, @who - SUBR(), where the subroutine READs anything. 2. Copying the primary data file using OS-level or Non-UV-aware utilities, but not correcting the new (copy) file header's pointer to the original's index files. Updates to the copy will be indexed on the original! Use SET.INDEX INFORM SET.INDEX TO NULL on the _copy_ of the data file. 3. Updating the index files explicitly. Usually happens when there is a voc pointer to the .../I_fname/INDEXnnn type-25 file. There is a 4th that I consider it a long-standing bug. It is known to IBM. And to Informix, Ardent, Vmark before them. 4. CNAME will not update any index on part of an id, e.g., FIELD( @ID, '*', 1 ). I was told CNAME uses an i/o mechanism different from every other update. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: Spam:RE: [U2] Index Problem
Another possible diagnostic method: Write a VOC that selects on each of the indexes, saves into lists, then selects again with the NO.INDEX clause, and saves that into separate lists. Then, LIST.DIFF between each with and without index selection. Report only if the resulting list is not empty. Or, better than report: rebuild the corrupted index. Laure Hansen, City of Redwood City Information Technology www.redwoodcity.org 1017 Middlefield Road Redwood City, CA 94063 Tel: 650-780-7087 Fax: 650-556-9204 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Thursday, February 08, 2007 8:36 AM To: u2-users@listserver.u2ug.org Subject: RE: Spam:RE: [U2] Index Problem From: Brenda Price 1. snip only necessary to rebuild the index(es) when you have a known corruption issue. snip Management decision from a long time ago and it is our comfort level to continue. I agree in principal with not rebuilding, but do not have 100% faith in any technology providing 100% reliability. 99.9% is sometimes not good enough. When clients are relying on us to provide their financials via web reports on a timely and accurate basis that .1% could lose us a big client and lots of money if it was wrong. Rather than rebuilding them, I would encourage you to just verify they are ok. Here's a way with no impact on your production system: Restore the file and its indexes TO your dev/test system FROM your standard backup (I assume you back up when the db is quiet!) Be sure to use SET.INDEX to correct the path. Then compare what's in the index with what should be in the index. I have a routine that does that, but I think a better way would be to --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index Problem
An exciting bit of info for UniVerse users out there! I just got confirmation from [EMAIL PROTECTED] that the ONLINE option of BUILD.INDEX in UniData appears as the CONCURRENT option in UniVerse as of 10.1 It has yet to make it into the standard documentation however. (Disclaimer: It's possible that I'm the last one on the planet to learn of this.) Perry Taylor Zirmed, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Thursday, February 08, 2007 12:15 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Index Problem I have not seen a problem since about UV9.6. 4 corrections to my own claim. There are 3 common sources of index corruption, all user-related: 1. Indexing a computed value, whose calculation does not depend ENTIRELY on the record being written. E.g.: - trans(), xlate(), T-correlatives - date(), time() - @variables such as @logname, @date, @who - SUBR(), where the subroutine READs anything. 2. Copying the primary data file using OS-level or Non-UV-aware utilities, but not correcting the new (copy) file header's pointer to the original's index files. Updates to the copy will be indexed on the original! Use SET.INDEX INFORM SET.INDEX TO NULL on the _copy_ of the data file. 3. Updating the index files explicitly. Usually happens when there is a voc pointer to the .../I_fname/INDEXnnn type-25 file. There is a 4th that I consider it a long-standing bug. It is known to IBM. And to Informix, Ardent, Vmark before them. 4. CNAME will not update any index on part of an id, e.g., FIELD( @ID, '*', 1 ). I was told CNAME uses an i/o mechanism different from every other update. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index Problem
snip (Disclaimer: It's possible that I'm the last one on the planet to learn of this.) /snip Nope... Which doesn't mean you weren't the second to last... :) Mark --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Index Problem
1. Indexing a computed value, whose calculation does not depend ENTIRELY on the record being written. E.g.: Or to put it another way.. The items in the record must depend on... The key, the whole key, and nothing but the key, so help me Codd.. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Index Problem
Last night a process that sleeps until around 2-3 am, then wakes up and does a BUILD.INDEX CUST.MSTR ALL failed. One of the indices BAD.ADDR was locked and failed which stopped all the other indices from building. So when we came in this morning nothing had been done from that point on. I've changed the process to build each index one at a time instead of the ALL option, so if one fails the rest continues, which will slow it down somewhat but is safer. Plus only the indices that are correctives will be rebuilt. This happened before in May 2006 and I am pretty sure that it was the exact index (BAD.ADDR) that hung us. The dict is this: BAD.ADDR 1 I 2 IF BAD.ADD = Y THEN 1 ELSE 0 3 4 51R 6S BAD.ADD 1A 244 3Bad^253Add 4 5 6 7 8 9L 101 On our test system, I've changed BAD.ADDR, deleted the index, created the index, and built it again as I was wondering if it was having problems from using another dictionary item. Once a window of opportunity happens I'll do the same on our live system. 1I 2 IF @RECORD44 = Y THEN 1 ELSE 0 3 4 51R 6S No one really thinks that is going to matter but I'm grasping at straws. Any ideas? Brenda Price Affiliated Acceptance Corporation Sunrise Beach, Missouri --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index Problem
Universe ??Version ?? Barry Rogen PNY Technologies, Inc. Senior Programmer/Analyst (973) 515 - 9700 ext 5327 [EMAIL PROTECTED] - Far better it is to dare mighty things, to win glorious triumphs even though checkered by failure, than to rank with those poor spirits who neither enjoy nor suffer much because they live in the gray twilight that knows neither victory nor defeat.t. roosevelt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brenda Price Sent: Tuesday, February 06, 2007 1:38 PM To: u2-users@listserver.u2ug.org Subject: [U2] Index Problem Last night a process that sleeps until around 2-3 am, then wakes up and does a BUILD.INDEX CUST.MSTR ALL failed. One of the indices BAD.ADDR was locked and failed which stopped all the other indices from building. So when we came in this morning nothing had been done from that point on. I've changed the process to build each index one at a time instead of the ALL option, so if one fails the rest continues, which will slow it down somewhat but is safer. Plus only the indices that are correctives will be rebuilt. This happened before in May 2006 and I am pretty sure that it was the exact index (BAD.ADDR) that hung us. The dict is this: BAD.ADDR 1 I 2 IF BAD.ADD = Y THEN 1 ELSE 0 3 4 51R 6S BAD.ADD 1A 244 3Bad^253Add 4 5 6 7 8 9L 101 On our test system, I've changed BAD.ADDR, deleted the index, created the index, and built it again as I was wondering if it was having problems from using another dictionary item. Once a window of opportunity happens I'll do the same on our live system. 1I 2 IF @RECORD44 = Y THEN 1 ELSE 0 3 4 51R 6S No one really thinks that is going to matter but I'm grasping at straws. Any ideas? Brenda Price Affiliated Acceptance Corporation Sunrise Beach, Missouri --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: Spam:RE: [U2] Index Problem
UniVerse 10.1.12 Reality Linux AS3 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barry Rogen Sent: Tuesday, February 06, 2007 1:37 PM To: u2-users@listserver.u2ug.org Subject: Spam:RE: [U2] Index Problem Universe ??Version ?? Barry Rogen PNY Technologies, Inc. Senior Programmer/Analyst (973) 515 - 9700 ext 5327 [EMAIL PROTECTED] - Far better it is to dare mighty things, to win glorious triumphs even though checkered by failure, than to rank with those poor spirits who neither enjoy nor suffer much because they live in the gray twilight that knows neither victory nor defeat.t. roosevelt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brenda Price Sent: Tuesday, February 06, 2007 1:38 PM To: u2-users@listserver.u2ug.org Subject: [U2] Index Problem Last night a process that sleeps until around 2-3 am, then wakes up and does a BUILD.INDEX CUST.MSTR ALL failed. One of the indices BAD.ADDR was locked and failed which stopped all the other indices from building. So when we came in this morning nothing had been done from that point on. I've changed the process to build each index one at a time instead of the ALL option, so if one fails the rest continues, which will slow it down somewhat but is safer. Plus only the indices that are correctives will be rebuilt. This happened before in May 2006 and I am pretty sure that it was the exact index (BAD.ADDR) that hung us. The dict is this: BAD.ADDR 1 I 2 IF BAD.ADD = Y THEN 1 ELSE 0 3 4 51R 6S BAD.ADD 1A 244 3Bad^253Add 4 5 6 7 8 9L 101 On our test system, I've changed BAD.ADDR, deleted the index, created the index, and built it again as I was wondering if it was having problems from using another dictionary item. Once a window of opportunity happens I'll do the same on our live system. 1I 2 IF @RECORD44 = Y THEN 1 ELSE 0 3 4 51R 6S No one really thinks that is going to matter but I'm grasping at straws. Any ideas? Brenda Price Affiliated Acceptance Corporation Sunrise Beach, Missouri --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index Problem
Hi Brenda, 1. It is probably only necessary to rebuild the index(es) when you have a known corruption issue. I think all indexed fields (I-type or not) are (re-)evaluated with every write; U2 indexes are self-updating. 2. If BAD.ADDR is just used to identify bad addresses, consider changing the I-type to return either 1 or null, and create the index using the NO.NULLS option? 3. However, does the BAD.ADDR field exist for selecting and totaling? Else why not just index the BAD.ADD field itself? It's probably marginally faster to build/maintain an index on a real field than on an I-type field. OT question for the list: is the practice of rebuilding indexes (nightly?) common? Why? I use a lot of indexes on large and active files, and very rarely have to rebuild them. Rebuilding indexes on a periodic basis looks like a little too much of the belt AND suspenders mindset. Are the U2 databases really so un-reliable that we have to resort to these sorts of hacks? (Actually, IMO they are very reliable and no you don't.) /Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brenda Price Sent: Tuesday, February 06, 2007 10:38 AM To: u2-users@listserver.u2ug.org Subject: [U2] Index Problem Last night a process that sleeps until around 2-3 am, then wakes up and does a BUILD.INDEX CUST.MSTR ALL failed. One of the indices BAD.ADDR was locked and failed which stopped all the other indices from building. So when we came in this morning nothing had been done from that point on. I've changed the process to build each index one at a time instead of the ALL option, so if one fails the rest continues, which will slow it down somewhat but is safer. Plus only the indices that are correctives will be rebuilt. This happened before in May 2006 and I am pretty sure that it was the exact index (BAD.ADDR) that hung us. The dict is this: BAD.ADDR 1 I 2 IF BAD.ADD = Y THEN 1 ELSE 0 3 4 51R 6S BAD.ADD 1A 244 3Bad^253Add 4 5 6 7 8 9L 101 On our test system, I've changed BAD.ADDR, deleted the index, created the index, and built it again as I was wondering if it was having problems from using another dictionary item. Once a window of opportunity happens I'll do the same on our live system. 1I 2 IF @RECORD44 = Y THEN 1 ELSE 0 3 4 51R 6S No one really thinks that is going to matter but I'm grasping at straws. Any ideas? Brenda Price Affiliated Acceptance Corporation Sunrise Beach, Missouri --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index Problem
If I remember correctly, and tell me if things have changed, indexed I-descriptors and correlatives that do translates from other files do not update indexes. This is one reason for building indexes periodically. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ballinger Sent: Tuesday, February 06, 2007 3:59 PM To: u2-users@listserver.u2ug.org Subject: Spam:RE: [U2] Index Problem Hi Brenda, 1. It is probably only necessary to rebuild the index(es) when you have a known corruption issue. I think all indexed fields (I-type or not) are (re-)evaluated with every write; U2 indexes are self-updating. 2. If BAD.ADDR is just used to identify bad addresses, consider changing the I-type to return either 1 or null, and create the index using the NO.NULLS option? 3. However, does the BAD.ADDR field exist for selecting and totaling? Else why not just index the BAD.ADD field itself? It's probably marginally faster to build/maintain an index on a real field than on an I-type field. OT question for the list: is the practice of rebuilding indexes (nightly?) common? Why? I use a lot of indexes on large and active files, and very rarely have to rebuild them. Rebuilding indexes on a periodic basis looks like a little too much of the belt AND suspenders mindset. Are the U2 databases really so un-reliable that we have to resort to these sorts of hacks? (Actually, IMO they are very reliable and no you don't.) /Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brenda Price Sent: Tuesday, February 06, 2007 10:38 AM To: u2-users@listserver.u2ug.org Subject: [U2] Index Problem Last night a process that sleeps until around 2-3 am, then wakes up and does a BUILD.INDEX CUST.MSTR ALL failed. One of the indices BAD.ADDR was locked and failed which stopped all the other indices from building. So when we came in this morning nothing had been done from that point on. I've changed the process to build each index one at a time instead of the ALL option, so if one fails the rest continues, which will slow it down somewhat but is safer. Plus only the indices that are correctives will be rebuilt. This happened before in May 2006 and I am pretty sure that it was the exact index (BAD.ADDR) that hung us. The dict is this: BAD.ADDR 1 I 2 IF BAD.ADD = Y THEN 1 ELSE 0 3 4 51R 6S BAD.ADD 1A 244 3Bad^253Add 4 5 6 7 8 9L 101 On our test system, I've changed BAD.ADDR, deleted the index, created the index, and built it again as I was wondering if it was having problems from using another dictionary item. Once a window of opportunity happens I'll do the same on our live system. 1I 2 IF @RECORD44 = Y THEN 1 ELSE 0 3 4 51R 6S No one really thinks that is going to matter but I'm grasping at straws. Any ideas? Brenda Price Affiliated Acceptance Corporation Sunrise Beach, Missouri --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index Problem {Unclassified}
We have no scheduled index re-builds here. Very, very occasionally we get an unexplainable error which 'goes away' when we rebuild the index on the file that's giving the error. The last time was a 'Write Error' [#040011] on a file with triggers and secondary indexes. Not actually sure whether dropping and re-creating the trigger, or dropping and re-building the index, cured the problem, the SysAdmin did both. By the way, OP's index looks horrendous: all the records in the file in two possible groups - Y and N. If you want an index that performs a bit better, I'd have values and maybe the @ID returned by the I-Descriptor, so that you can say NO.NULLS and have an index of Bad Addresses (?) that would work properly. Maybe the reason this particular index needs re-building is because of the bad distribution of keys? Just my $0.02 worth Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ballinger Sent: Wednesday, 7 February 2007 10:59 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Index Problem [snip] OT question for the list: is the practice of rebuilding indexes (nightly?) common? Why? I use a lot of indexes on large and active files, and very rarely have to rebuild them. Rebuilding indexes on a periodic basis looks like a little too much of the belt AND suspenders mindset. Are the U2 databases really so un-reliable that we have to resort to these sorts of hacks? (Actually, IMO they are very reliable and no you don't.) /Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Thank you Ken, We have modified the subroutine according to your suggestions. It is working as expected. Thank you again for your help. Regards Kafsat -Original Message- From: Ken Wallis [mailto:[EMAIL PROTECTED] Sent: Thursday, 4 November 2004 10:57 AM To: [EMAIL PROTECTED] Subject: RE: [U2] Index problem Kafsat, I believe that if you pass the record data into the subroutine as a parameter using @RECORD instead of re-reading it from the file, then you will have a better chance of getting the behaviour you want: V SUBR(KAFSATS,@ID,@RECORD,OTHERSTUFF) ... SUBROUTINE KAFSATS(RESULT, REC_ID, REC_DATA, OTHERSTUFF) ... RETURN END Cheers, Ken -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of kafsat taiyus Sent: Thursday, 4 November 2004 11:00 AM To: '[EMAIL PROTECTED]' Subject: RE: [U2] Index problem Thank you everybody for all your answers. I have used debug and stepped though the subroutine. While adding a new record the program is reading the new non existing record from the same file and not returning anything for the virtual field. This is one reason for not updating the index in the first place. I have tried to write same record twice with the same ID overwriting the existing record. In this case the subroutine return the correct value but the index still does not get updated. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ This email and any attachments are confidential and intended solely for the use of the person or entity to whom they are addressed. If you are not the intended recipient, please do not disclose, store, copy or take any action in reliance on it or them. If you have received this message in error, please tell us by reply email (or telephone + 61 (0) 3 9274 9100) and delete all copies on your system. Any opinion, advice or information in this email is not necessarily that of the owners or officers of this company. Please advise us immediately if you or your employer do not consent to email for messages of this type. Retail Decisions has taken reasonable precautions to ensure that any attachment to this email has been swept for viruses. However, we cannot accept any liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer system may be viewed by other Retail Decisions employees or officers strictly in accordance with law. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Hey thanks Charles! That did look like my old cheat-sheet, now ... I found the manual for uv on IBM site (http://publibfi.boulder.ibm.com/epubs/pdf/25119270.pdf) It doesn't offer any more info that what you posted (and took a lot longer to download :-) . Any where I can find ... 1. a more detailed internals description of processor mode and dispatch type? 2. if this information is different for Unidata? (the unidata doc didn't seem to refer to more than two lines of the VOC entry for Verbs. 3. Does the flavor (information vs pick) override the dispatch/mode, the dispatch/mode override the flavor or something entirely different? Thanks again for the listing. I -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Thursday, November 04, 2004 4:17 PM To: [EMAIL PROTECTED] Subject: RE: [U2] Index problem Oops, the chart spilled over to pg 3-16, so I fixed it below. cds -Original Message- From: Stevenson, Charles Sent: Thursday, November 04, 2004 3:10 PM To: '[EMAIL PROTECTED]' Subject: RE: [U2] Index problem From: Doyen Klein Can someone post or point to the doc which describes all the convoluted and obscure things one can do when one changes these letters? Doyen, Here's a raw cutpaste from adobe reader from sysdesc.pdf, System Description, UV10, pg 3-15,16 : processor mode is used by the command processor to perform the required setup before executing the verb. It can be one or more of the following codes: Code Processor Mode A Alternate query syntax B not used C External program COMO D Pass DATA to subprocess E Use Win32 expansion routine (Windows NT only) F Pass format via environment variable G Allowed in an SQL CALL statement H EXECUTE and PERFORM can use in a transaction I Interrupt control K Keep select list M Maps EXECUTE output to internal character set (NLS only) N Does not set @SYSTEM.RETURN.CODE P Parenthetical options are available Q SQL mode R Backslashes ( \ ) can be used to quote strings S Use select list T Terminal mode change U Add pathname of the UV account directory before processor name V Function specified by field 5 X Read DATA if a select list is active The rest of the attributes for V-items are described in the same section, as are other VOC types beside V-items. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
From: Doyen Klein I found the manual for uv on IBM site (http://publibfi.boulder.ibm.com/epubs/pdf/25119270.pdf) Any where I can find ... 1. a more detailed internals description of processor mode and dispatch type? Not that I know of. Just the whole VOC section (chapter 3) in the System Description manual. You can make some inferences by looking in NEWACC to see how various UV-supplied verbs are flagged. 2. if this information is different for Unidata? (the unidata doc didn't seem to refer to more than two lines of the VOC entry for Verbs. It is UV-specific. 3. Does the flavor (information vs pick) override the dispatch/mode, the dispatch/mode override the flavor or something entirely different? Entirely different . . . I think. cds --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Index problem
Fred Finken [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Here's an idea that I haven't actually tried, but it sure seems like it should work: You have two related files - say ORDERS and CUSTOMERS. You want any change to CUSTOMERS name to be reflected in the ORDERS file's CUSTOMER.NAME index. First index the customer number in the ORDERS file. Add date time fields to ORDERS. Then put a trigger on CUSTOMERS. The trigger routine uses the customer number index on ORDERS to determine which orders belong to the customer being updated. Using this info, the trigger stamps those ORDERS items with the date time of the customer update. Now because the appropriate ORDERS items are being updated, their indices will all be re-evaluated and if the customer name has changed, the CUSTOMER.NAME index will be updated. Doesn't work Fred. because the appropriate ORDERS items are being updated, their indices will all be re-evaluated this is true, but... and if the customer name has changed ...this is where a problem lies. The index software evaluates CUSTOMER.NAME before and after the ORDERS file is updated - any change it detects will be between these two points, not from where the index was last updated and now. Both checks will give the same name so the index won't be updated. (As it happens the old name, because using a trigger on CUSTOMERS to run this ORDERS update means that the new name has not yet been written). What would be great is if Unidata provided a facility to update an index in a file programatically. Something like: err=CHANGEINDEXITEM(file.var, index.name, key.val, original.index.value, new.index.value) and I suppose for completeness: err=DELETEINDEXITEM(file.var, index.name, key.val, original.index.value) err=ADDINDEXITEM(file.var, index.name, key.val, new.index.value) They could put a '!' warning in the manual saying use at your own risk. Your CUSTOMERS trigger would then call this for each item in the ORDERS file with that customer... CHANGEINDEXITEM(fpORDERS,CUSTOMER.NAME,ORDERNO,OLD.NAME,NEW.NAME) Simon --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Phil: What I don't understand about this conversation is why would one expect any different functionality from the dbms? This has been, in my experience, the way indexes have always been on the mvDbms products; whether they be U2, D3, or whatever. When an index is created, it is updated if, and only if, the file it was created for changes. Your example indicates an index on DETAIL that translates HEADER information. Since DETAIL is written first, hence no HEADER information exists, the index on DETAIL is updated with NULL. When HEADER is written, it is completely irrelevant what indexes exist on DETAIL (as it is irrelevant what indexes exist on CUSTOMER, RECEIPTS, etc). The only index that will be updated when HEADER is written are indexes on HEADER. This is a common problem with an mvDbms index structure. Your solution is probably the only practical one available. I've been fiddling with the possibility of doing an after update trigger to update the related DETAIL but that significantly slows down batch processes and really messes up my COPYs and RESTOREs too. So I've found your solution to be the best, in the aggregate, where a file is kept of changes in the DETAIL file and a process then reindexes DETAIL on a periodic basis. You may want to test, however, keeping a file of changed items in DETAIL. Then periodically reading/writing the DETAIL record(s) and see if the index is then updated, even though there is no change to the DETAIL. This might work and be a more practical solution. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Warren, Phil Sent: Wednesday, November 03, 2004 6:25 AM To: '[EMAIL PROTECTED]' Subject: RE: [U2] Index problem We've run into a similar problem with virtual attributes that reference other files in all versions of UniData through to version 6.0.8. I wonder if this might be a similar 'anomaly' For example, In our case we have 2 order files, named HEADER and DETAIL. A virtual attribute exists in the DETAIL file which references the HEADER file. When the DETAIL record(s) are written out before the HEADER record, UniData does not update the DETAIL index when the HEADER file is written, causing a null value when the DETAIL index is used. As in your case, when another attribute is used, to select the DETAIL file, which does not use the index, the items are selected as expected. The only work around that we've used, is to rebuild the index file daily. Perhaps there is a better work around or fix? -Phil- -Original Message- From: kafsat taiyus [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 10:00 PM To: '[EMAIL PROTECTED]' Subject: [U2] Index problem We have one Unidata 5.1 data file with a virtual attribute. The virtual dictionary calls a Unibasic subroutine and returns a single value data from a multi value attribute from within the same file. We have an index on the virtual attribute. When new records are added to the file Unidata does not update the index on the virtual attribute. After adding new records that returns XXX for the virtual attribute the command LIST FILE_NAME WITH VIRTUAL_ATT = XXX does not return any record. But the command LIST FILE_NAME NO.INDEX WITH VIRTUAL_ATT = XXX finds the record. The command LIST FILE_NAME WITH VIRTUAL_ATT = XXX works only after rebuilding the index using REBUILD.INDEX command. Do you know why is it happening and how to fix it? Thank you in anticipation. Regards Kafsat This email and any attachments are confidential and intended solely for the use of the person or entity to whom they are addressed. If you are not the intended recipient, please do not disclose, store, copy or take any action in reliance on it or them. If you have received this message in error, please tell us by reply email (or telephone + 61 (0) 3 9274 9100) and delete all copies on your system. Any opinion, advice or information in this email is not necessarily that of the owners or officers of this company. Please advise us immediately if you or your employer do not consent to email for messages of this type. Retail Decisions has taken reasonable precautions to ensure that any attachment to this email has been swept for viruses. However, we cannot accept any liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer system may be viewed by other Retail Decisions employees or officers strictly in accordance with law. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
[EMAIL PROTECTED] wrote: Phil: What I don't understand about this conversation is why would one expect any different functionality from the dbms? This has been, in my experience, the way indexes have always been on the mvDbms products; whether they be U2, D3, or whatever. When an index is created, it is updated if, and only if, the file it was created for changes. Your example indicates an index on DETAIL that translates HEADER information. Since DETAIL is written first, hence no HEADER information exists, the index on DETAIL is updated with NULL. When HEADER is written, it is completely irrelevant what indexes exist on DETAIL (as it is irrelevant what indexes exist on CUSTOMER, RECEIPTS, etc). The only index that will be updated when HEADER is written are indexes on HEADER. And the reason rewriting the record doesn't correct the index is easily explained too. Bear in mind it doesn't create the original index (correctly) because the before snapshot is wrong. It doesn't then correct the index because when you rewrite it the before snapshot is correct, the before and after indices appear to be the same, so optimisation means it doesn't bother with an update (and doesn't realise the index is wrong). Cheers, Wol --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
This (create a trigger in the header file that updates and re-files the detail item(s)) is what I have done on D3 systems. The only thing I might add is that I phantom off the update and include a 'sleep 5' (typically create a run-once proc and phantom that off) so that when the detail update happens the header has already been filed. It's not elegant, but it does work. Scott Ballinger Pareto Corporation Edmonds WA USA 725 670 0831 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alfke, Colin Sent: Wednesday, November 03, 2004 12:06 PM To: [EMAIL PROTECTED] Subject: RE: [U2] Index problem [snip] Another work around is to have a trigger on the header file re-file the detail items that reference it so that the index is properly updated. I'm not sure if you'll have to change the detail item or not for it to cause the index to be updated. [snip] --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
I've been out sick for a month and am jumping into the middle of this thread. I gather that someone wants to maintain an index on a TRANS() result, but is frustrated by UV or UD's failure to maintain the index. Here is a good workaround using my own verb, XSELECT, first implimented when we were a beta site for PI 7.0 when indexes were introduced. For example: Dict... Id... Type.. Field or calculation.. ORD.DTL HDR.ID D 5 or maybe V FIELD( @ID, '*', 1 ) ORD.DTL CUST.NAME V TRANS( ORD.HDR, HDR.ID, CUST.NAME, 'X' ) ORD.HDR CUST.NAME D 2 you *want* to CREATE.INDEX ORD.DTL CUST.NAME but it isn't maintained by UD. I get around that with my own XSELECT verb. I index both: - ORD.HDR CUST.NAME - 0RD.DTL HDR.ID but not ORD.DTL CUST.NAME ! Then 2 steps at TCL or pararaph: SELECT ORD.HDR WITH CUST.NAME = XYZ ABC etc... XSELECT ORD.DTL HDR.ID XSELECT takes an active select list of ORD.HDR IDs and essentially does: DTL.LIST = '' LOOP WHILE READNEXT HDR.ID FROM 0 SELECTINDEX 'HDR.ID', HDR.ID FROM DTL.FVAR TO 10 READLIST TEMP.LIST FROM 10 DTL.LIST-1 = TEMP.LIST REPEAT FORMLIST DTL.LIST TO 0 STOP ending with an active select list of all ORD.DTL ids that have CUST.NAME resolved to XYZ or ABC. It is fast. Of course, my real XSELECT is a general utility with generalized variable names, but you get the idea. In Universe the VOC V-item for XSELECT points to a catalogued basic program and has a K in 4, meaning keep select list active when done executing. I don't know how UD handles this. If I guessed at the original question correctly, I think that is what is wanted. If not, I hope you found it interesting reading anyway. cds --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
I recently suspected that these mystery letters might help solve my mlist not found problem, but I misplaced my cheat-sheet (It was universe anyway) Can someone post or point to the doc which describes all the convoluted and obscure things one can do when one changes these letters? -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Thursday, November 04, 2004 1:44 PM To: [EMAIL PROTECTED] Subject: RE: [U2] Index problem In Universe the VOC V-item for XSELECT points to a catalogued basic program and has a K in 4, meaning keep select list active when done executing. I don't know how UD handles this. u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Wouldn't it be simpler to... 1. Maintain an attribute in dict ORD.HDR that contains all of the related ORD.DTL ids (or an I-type that builds such a list), perhaps called ORD.DTL.IDS 2. SELECT ORD.HDR WITH CUST.NAME EQ ABC XYZ ORD.DTL.IDS Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Thursday, November 04, 2004 12:44 PM To: [EMAIL PROTECTED] Subject: RE: [U2] Index problem [snip] Then 2 steps at TCL or pararaph: SELECT ORD.HDR WITH CUST.NAME = XYZ ABC etc... XSELECT ORD.DTL HDR.ID XSELECT takes an active select list of ORD.HDR IDs and essentially does: DTL.LIST = '' LOOP WHILE READNEXT HDR.ID FROM 0 SELECTINDEX 'HDR.ID', HDR.ID FROM DTL.FVAR TO 10 READLIST TEMP.LIST FROM 10 DTL.LIST-1 = TEMP.LIST REPEAT FORMLIST DTL.LIST TO 0 STOP ending with an active select list of all ORD.DTL ids that have CUST.NAME resolved to XYZ or ABC. It is fast. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Scott, Well, I suppose sometimes it would. But I was aiming at a general solution. For example, suppose CUST.NAME is stored in a CUSTOMER file. And CUST.ID is an attribute in any number of files, such as ORDERS, INVOICES, CONTRACTS, SALESMAN, etc... Would you want to maintain 4 separate multivalued attributes in CUSTOMER to track all ORDERS, INVOICES, CONTRACTS, SALESMAN, etc. ids? The technique I described would work if CUSTOMER CUST.NAME were indexed and the CUST.ID field of any or all of those supposed files were also indexed. One can think of numerous other examples. And sometimes creating an index is easier than retrofitting the file with new attributes and reworking the ap to maintain the mv-list. But even in the simple ORD.HDR/ORD.DTL example, the simplicity is debateable. Historically, I know that old Pickies do it the way you described, but I'd sooner let the system maintain the list (via indexing ODR.DTL HDR.ID) rather than explicitly maintaining the relationship programmatically. Admittedly, it shifts what's simple and what's complex. But some of us old Primates have used indexes for about a decade and a half, so we're comfortable with that. I also have a general-purpose I-descriptor subroutine that I use for doing SELECTINDEX from RetrieVe/UniQuery. It yields the same MV-list of ORD.DTL ids that you would maintain as an mv attribute, but via an I- or V-descriptor. Another complexity you might think, but once the general-purpose utility subroutine is written, the simplicity at the higher level is restored. That's how I see it anyway, cds -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ballinger Sent: Thursday, November 04, 2004 2:18 PM To: [EMAIL PROTECTED] Subject: RE: [U2] Index problem Wouldn't it be simpler to... 1. Maintain an attribute in dict ORD.HDR that contains all of the related ORD.DTL ids (or an I-type that builds such a list), perhaps called ORD.DTL.IDS 2. SELECT ORD.HDR WITH CUST.NAME EQ ABC XYZ ORD.DTL.IDS Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Thursday, November 04, 2004 12:44 PM To: [EMAIL PROTECTED] Subject: RE: [U2] Index problem [snip] Then 2 steps at TCL or pararaph: SELECT ORD.HDR WITH CUST.NAME = XYZ ABC etc... XSELECT ORD.DTL HDR.ID XSELECT takes an active select list of ORD.HDR IDs and essentially does: DTL.LIST = '' LOOP WHILE READNEXT HDR.ID FROM 0 SELECTINDEX 'HDR.ID', HDR.ID FROM DTL.FVAR TO 10 READLIST TEMP.LIST FROM 10 DTL.LIST-1 = TEMP.LIST REPEAT FORMLIST DTL.LIST TO 0 STOP ending with an active select list of all ORD.DTL ids that have CUST.NAME resolved to XYZ or ABC. It is fast. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Index problem
REPOSTED FOR A NON-MEMBER [EMAIL PROTECTED] Kafsat, Check that the index is enabled. Perhaps you could post output from LIST.INDEX. Cheers, Ken The information contained in this email is intended only for the person or entity to which it is addressed. If you are not the intended recipient please delete the message and notify the sender. It may contain privileged and/or confidential material. The use, copying or distribution of this information by anyone other than he intended recipient is strictly prohibited. Any views or opinions presented are solely those of the individual sender, except where the sender specifically states hem to be the views of Paperless Warehousing Pty Ltd. This e-mail message has been scanned and cleared by Antivirus Technologies. Thank You. [demime 1.01d removed an attachment of type text/x-vcard which had a name of u2ug.vcf] --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Perhaps its to do with the processing order, Unidata might be updating the index on the previous contents? This would seem to fit in with the rebuild putting the item into the index. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kafsat taiyus Sent: 03 November 2004 03:00 To: '[EMAIL PROTECTED]' Subject: [U2] Index problem We have one Unidata 5.1 data file with a virtual attribute. The virtual dictionary calls a Unibasic subroutine and returns a single value data from a multi value attribute from within the same file. We have an index on the virtual attribute. When new records are added to the file Unidata does not update the index on the virtual attribute. After adding new records that returns XXX for the virtual attribute the command LIST FILE_NAME WITH VIRTUAL_ATT = XXX does not return any record. But the command LIST FILE_NAME NO.INDEX WITH VIRTUAL_ATT = XXX finds the record. The command LIST FILE_NAME WITH VIRTUAL_ATT = XXX works only after rebuilding the index using REBUILD.INDEX command. Do you know why is it happening and how to fix it? Thank you in anticipation. Regards Kafsat This email and any attachments are confidential and intended solely for the use of the person or entity to whom they are addressed. If you are not the intended recipient, please do not disclose, store, copy or take any action in reliance on it or them. If you have received this message in error, please tell us by reply email (or telephone + 61 (0) 3 9274 9100) and delete all copies on your system. Any opinion, advice or information in this email is not necessarily that of the owners or officers of this company. Please advise us immediately if you or your employer do not consent to email for messages of this type. Retail Decisions has taken reasonable precautions to ensure that any attachment to this email has been swept for viruses. However, we cannot accept any liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer system may be viewed by other Retail Decisions employees or officers strictly in accordance with law. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone +44 (0)20 7896 0011 and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Markets Limited and IG Index Plc are authorised and regulated by the Financial Services Authority and, in Australia, by the Australian Securities and Investments Commission. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
You said when new records are added and this quite possibly might hold your solution. Are you sure that the virtual is actually calculating a value on this new record when that record is saved? Just a thought, but as another person has mentioned it sounds like a timing issue. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kafsat taiyus Sent: Tuesday, November 02, 2004 8:00 PM To: '[EMAIL PROTECTED]' Subject: [U2] Index problem We have one Unidata 5.1 data file with a virtual attribute. The virtual dictionary calls a Unibasic subroutine and returns a single value data from a multi value attribute from within the same file. We have an index on the virtual attribute. When new records are added to the file Unidata does not update the index on the virtual attribute. After adding new records that returns XXX for the virtual attribute the command LIST FILE_NAME WITH VIRTUAL_ATT = XXX does not return any record. But the command LIST FILE_NAME NO.INDEX WITH VIRTUAL_ATT = XXX finds the record. The command LIST FILE_NAME WITH VIRTUAL_ATT = XXX works only after rebuilding the index using REBUILD.INDEX command. Do you know why is it happening and how to fix it? Thank you in anticipation. Regards Kafsat This email and any attachments are confidential and intended solely for the use of the person or entity to whom they are addressed. If you are not the intended recipient, please do not disclose, store, copy or take any action in reliance on it or them. If you have received this message in error, please tell us by reply email (or telephone + 61 (0) 3 9274 9100) and delete all copies on your system. Any opinion, advice or information in this email is not necessarily that of the owners or officers of this company. Please advise us immediately if you or your employer do not consent to email for messages of this type. Retail Decisions has taken reasonable precautions to ensure that any attachment to this email has been swept for viruses. However, we cannot accept any liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer system may be viewed by other Retail Decisions employees or officers strictly in accordance with law. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
kafsat taiyus We have an index on the virtual attribute. When new records are added to the file Unidata does not update the index on the virtual attribute. I don't know if it's fixable, but it's something we're aware of and it's why we rebuild some indices weekly, and why we run some jobs in a way that intentionally does NOT use the index that we know will be out of date. Logically, if field2 runs a subroutine that looks at field3, and field3 gets changed... I don't see how the system can be expected to know that the index on field2 needs to be updated. -- Wendy Smoak Applications Systems Analyst, Sr. Arizona State University, PA, IRM --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Logically, if field2 runs a subroutine that looks at field3, and field3 gets changed... I don't see how the system can be expected to know that the index on field2 needs to be updated. Whoa... Sounds like you're saying that no virtual indices should work (whether or not a subroutine is involved). I can see where a virtual referring to another item (in the same file or another file) couldn't be expected to stay up-to-date with changes, but if the references are to the same item, they should work. -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Fred Finken Sounds like you're saying that no virtual indices should work (whether or not a subroutine is involved). I can see where a virtual referring to another item (in the same file or another file) couldn't be expected to stay up-to-date with changes, but if the references are to the same item, they should work. You're right-- the problem we see occurs when the value that changed is in another _file_ not another field. So a trans that pulls a field from another file, for example, won't get updated. -- Wendy Smoak --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Depends on how you're referring to the field in the subroutine. If its being read from the file then I can see that would never work. If its being passed as an argument then maybe. As some other posters have said, we really need to see the subroutine to help. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Finken Sent: 03 November 2004 15:59 To: [EMAIL PROTECTED] Subject: RE: [U2] Index problem Logically, if field2 runs a subroutine that looks at field3, and field3 gets changed... I don't see how the system can be expected to know that the index on field2 needs to be updated. Whoa... Sounds like you're saying that no virtual indices should work (whether or not a subroutine is involved). I can see where a virtual referring to another item (in the same file or another file) couldn't be expected to stay up-to-date with changes, but if the references are to the same item, they should work. -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone +44 (0)20 7896 0011 and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Markets Limited and IG Index Plc are authorised and regulated by the Financial Services Authority and, in Australia, by the Australian Securities and Investments Commission. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Wendy Smoak You're right-- the problem we see occurs when the value that changed is in another _file_ not another field. So a trans that pulls a field from another file, for example, won't get updated. Here's an idea that I haven't actually tried, but it sure seems like it should work: You have two related files - say ORDERS and CUSTOMERS. You want any change to CUSTOMERS name to be reflected in the ORDERS file's CUSTOMER.NAME index. First index the customer number in the ORDERS file. Add date time fields to ORDERS. Then put a trigger on CUSTOMERS. The trigger routine uses the customer number index on ORDERS to determine which orders belong to the customer being updated. Using this info, the trigger stamps those ORDERS items with the date time of the customer update. Now because the appropriate ORDERS items are being updated, their indices will all be re-evaluated and if the customer name has changed, the CUSTOMER.NAME index will be updated. -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
We've run into a similar problem with virtual attributes that reference other files in all versions of UniData through to version 6.0.8. I wonder if this might be a similar 'anomaly' For example, In our case we have 2 order files, named HEADER and DETAIL. A virtual attribute exists in the DETAIL file which references the HEADER file. When the DETAIL record(s) are written out before the HEADER record, UniData does not update the DETAIL index when the HEADER file is written, causing a null value when the DETAIL index is used. As in your case, when another attribute is used, to select the DETAIL file, which does not use the index, the items are selected as expected. The only work around that we've used, is to rebuild the index file daily. Perhaps there is a better work around or fix? -Phil- -Original Message- From: kafsat taiyus [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 10:00 PM To: '[EMAIL PROTECTED]' Subject: [U2] Index problem We have one Unidata 5.1 data file with a virtual attribute. The virtual dictionary calls a Unibasic subroutine and returns a single value data from a multi value attribute from within the same file. We have an index on the virtual attribute. When new records are added to the file Unidata does not update the index on the virtual attribute. After adding new records that returns XXX for the virtual attribute the command LIST FILE_NAME WITH VIRTUAL_ATT = XXX does not return any record. But the command LIST FILE_NAME NO.INDEX WITH VIRTUAL_ATT = XXX finds the record. The command LIST FILE_NAME WITH VIRTUAL_ATT = XXX works only after rebuilding the index using REBUILD.INDEX command. Do you know why is it happening and how to fix it? Thank you in anticipation. Regards Kafsat This email and any attachments are confidential and intended solely for the use of the person or entity to whom they are addressed. If you are not the intended recipient, please do not disclose, store, copy or take any action in reliance on it or them. If you have received this message in error, please tell us by reply email (or telephone + 61 (0) 3 9274 9100) and delete all copies on your system. Any opinion, advice or information in this email is not necessarily that of the owners or officers of this company. Please advise us immediately if you or your employer do not consent to email for messages of this type. Retail Decisions has taken reasonable precautions to ensure that any attachment to this email has been swept for viruses. However, we cannot accept any liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer system may be viewed by other Retail Decisions employees or officers strictly in accordance with law. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Index problem
Apologies if this has already been said but I have dived in part way through this thread. The only work around that we've used, is to rebuild the index file daily. Perhaps there is a better work around or fix? There is one and only one rule that determines whether you can build an index on an I-type: The I-type expression must always produce the same result for any particular database record. The two common examples that we quote in teaching training courses are 1. An I-type that takes a date of birth and calculates the person's age in years. An index built on this will be wrong as soon as someone has a birthday. There is no way in which the system could update such an index automatically. 2. An I-type that takes in data from another file using TRANS() [This is your problem]. If the other file changes, the index will not be updated. Again, there is no practical way in which this could be done automatically. If you have this problem, there are two solutions... 1. Rebuild the indices as often as needed. This probably implies that you will get erroneous data between rebuilds. 2. Redesign the application to abide by this rule. Sadly, this is a very common mistake. I have spent many happy hours redesigning client's databases to get around their errors. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
I believe it's even in the documentation that UniData will only update an index on the file that is being updated and not any other files that may have an index that references that file. Another work around is to have a trigger on the header file re-file the detail items that reference it so that the index is properly updated. I'm not sure if you'll have to change the detail item or not for it to cause the index to be updated. hth Colin Alfke Calgary - soon to head to LA -Original Message- From: Warren, Phil [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 7:25 AM To: '[EMAIL PROTECTED]' Subject: RE: [U2] Index problem We've run into a similar problem with virtual attributes that reference other files in all versions of UniData through to version 6.0.8. I wonder if this might be a similar 'anomaly' For example, In our case we have 2 order files, named HEADER and DETAIL. A virtual attribute exists in the DETAIL file which references the HEADER file. When the DETAIL record(s) are written out before the HEADER record, UniData does not update the DETAIL index when the HEADER file is written, causing a null value when the DETAIL index is used. As in your case, when another attribute is used, to select the DETAIL file, which does not use the index, the items are selected as expected. The only work around that we've used, is to rebuild the index file daily. Perhaps there is a better work around or fix? -Phil- --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Thank you everybody for all your answers. I have used debug and stepped though the subroutine. While adding a new record the program is reading the new non existing record from the same file and not returning anything for the virtual field. This is one reason for not updating the index in the first place. I have tried to write same record twice with the same ID overwriting the existing record. In this case the subroutine return the correct value but the index still does not get updated. I have located following text from the documentations A virtual attribute that contains a TRANS statement to another file, or the same file, is not a recommended use of an alternate key index, unless the file being translated to does not change. If the file being translated to does change, the alternate key index is not updated. Therefore, to obtain accurate results from a UniQuery statement, the alternate key index would need to be rebuilt each time the associated file is updated. Our problem is actually similar to Martin's birth year calculation example. The subroutine is looking at the same file for data. I understand the problem now. We should be able to implement a work around. Thank you again. Regards Kafsat -Original Message- From: Alfke, Colin [mailto:[EMAIL PROTECTED] Sent: Thursday, 4 November 2004 6:06 AM To: [EMAIL PROTECTED] Subject: RE: [U2] Index problem I believe it's even in the documentation that UniData will only update an index on the file that is being updated and not any other files that may have an index that references that file. Another work around is to have a trigger on the header file re-file the detail items that reference it so that the index is properly updated. I'm not sure if you'll have to change the detail item or not for it to cause the index to be updated. hth Colin Alfke Calgary - soon to head to LA -Original Message- From: Warren, Phil [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 7:25 AM To: '[EMAIL PROTECTED]' Subject: RE: [U2] Index problem We've run into a similar problem with virtual attributes that reference other files in all versions of UniData through to version 6.0.8. I wonder if this might be a similar 'anomaly' For example, In our case we have 2 order files, named HEADER and DETAIL. A virtual attribute exists in the DETAIL file which references the HEADER file. When the DETAIL record(s) are written out before the HEADER record, UniData does not update the DETAIL index when the HEADER file is written, causing a null value when the DETAIL index is used. As in your case, when another attribute is used, to select the DETAIL file, which does not use the index, the items are selected as expected. The only work around that we've used, is to rebuild the index file daily. Perhaps there is a better work around or fix? -Phil- --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ This email and any attachments are confidential and intended solely for the use of the person or entity to whom they are addressed. If you are not the intended recipient, please do not disclose, store, copy or take any action in reliance on it or them. If you have received this message in error, please tell us by reply email (or telephone + 61 (0) 3 9274 9100) and delete all copies on your system. Any opinion, advice or information in this email is not necessarily that of the owners or officers of this company. Please advise us immediately if you or your employer do not consent to email for messages of this type. Retail Decisions has taken reasonable precautions to ensure that any attachment to this email has been swept for viruses. However, we cannot accept any liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer system may be viewed by other Retail Decisions employees or officers strictly in accordance with law. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
[EMAIL PROTECTED] wrote: We have one Unidata 5.1 data file with a virtual attribute. The virtual dictionary calls a Unibasic subroutine and returns a single value data from a multi value attribute from within the same file. We have an index on the virtual attribute. When new records are added to the file Unidata does not update the index on the virtual attribute. After adding new records that returns XXX for the virtual attribute the command LIST FILE_NAME WITH VIRTUAL_ATT = XXX does not return any record. But the command LIST FILE_NAME NO.INDEX WITH VIRTUAL_ATT = XXX finds the record. The command LIST FILE_NAME WITH VIRTUAL_ATT = XXX works only after rebuilding the index using REBUILD.INDEX command. Do you know why is it happening and how to fix it? Kafsat, Check that the index is enabled. Perhaps you could post output from LIST.INDEX. Cheers, Ken The information contained in this email is intended only for the person or entity to which it is addressed. If you are not the intended recipient please delete the message and notify the sender. It may contain privileged and/or confidential material. The use, copying or distribution of this information by anyone other than he intended recipient is strictly prohibited. Any views or opinions presented are solely those of the individual sender, except where the sender specifically states hem to be the views of Paperless Warehousing Pty Ltd. This e-mail message has been scanned and cleared by Antivirus Technologies. Thank You. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
Kafsat, I believe that if you pass the record data into the subroutine as a parameter using @RECORD instead of re-reading it from the file, then you will have a better chance of getting the behaviour you want: V SUBR(KAFSATS,@ID,@RECORD,OTHERSTUFF) ... SUBROUTINE KAFSATS(RESULT, REC_ID, REC_DATA, OTHERSTUFF) ... RETURN END Cheers, Ken -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of kafsat taiyus Sent: Thursday, 4 November 2004 11:00 AM To: '[EMAIL PROTECTED]' Subject: RE: [U2] Index problem Thank you everybody for all your answers. I have used debug and stepped though the subroutine. While adding a new record the program is reading the new non existing record from the same file and not returning anything for the virtual field. This is one reason for not updating the index in the first place. I have tried to write same record twice with the same ID overwriting the existing record. In this case the subroutine return the correct value but the index still does not get updated. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Index problem
You shouldn't be reading the record in the subroutine - it does not yet exist in the file. You should ALWAYS use @RECORD to refer to the current record and @ID to refer to the current key. You should either directly refer to @RECORD in your subroutine (and remove the READ statement) or alternatively you could pass @RECORD to the subroutine from the i-type as an argument. Another solution would be to code everything directly in the i-type, why use a subroutine if all it is doing is manipulating data in a single record? Adrian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kafsat taiyus Sent: Thursday, 4 November 2004 8:00 AM To: '[EMAIL PROTECTED]' Subject: RE: [U2] Index problem Thank you everybody for all your answers. I have used debug and stepped though the subroutine. While adding a new record the program is reading the new non existing record from the same file and not returning anything for the virtual field. This is one reason for not updating the index in the first place. I have tried to write same record twice with the same ID overwriting the existing record. In this case the subroutine return the correct value but the index still does not get updated. I have located following text from the documentations A virtual attribute that contains a TRANS statement to another file, or the same file, is not a recommended use of an alternate key index, unless the file being translated to does not change. If the file being translated to does change, the alternate key index is not updated. Therefore, to obtain accurate results from a UniQuery statement, the alternate key index would need to be rebuilt each time the associated file is updated. Our problem is actually similar to Martin's birth year calculation example. The subroutine is looking at the same file for data. I understand the problem now. We should be able to implement a work around. Thank you again. Regards Kafsat --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
[U2] Index problem
We have one Unidata 5.1 data file with a virtual attribute. The virtual dictionary calls a Unibasic subroutine and returns a single value data from a multi value attribute from within the same file. We have an index on the virtual attribute. When new records are added to the file Unidata does not update the index on the virtual attribute. After adding new records that returns XXX for the virtual attribute the command LIST FILE_NAME WITH VIRTUAL_ATT = XXX does not return any record. But the command LIST FILE_NAME NO.INDEX WITH VIRTUAL_ATT = XXX finds the record. The command LIST FILE_NAME WITH VIRTUAL_ATT = XXX works only after rebuilding the index using REBUILD.INDEX command. Do you know why is it happening and how to fix it? Thank you in anticipation. Regards Kafsat This email and any attachments are confidential and intended solely for the use of the person or entity to whom they are addressed. If you are not the intended recipient, please do not disclose, store, copy or take any action in reliance on it or them. If you have received this message in error, please tell us by reply email (or telephone + 61 (0) 3 9274 9100) and delete all copies on your system. Any opinion, advice or information in this email is not necessarily that of the owners or officers of this company. Please advise us immediately if you or your employer do not consent to email for messages of this type. Retail Decisions has taken reasonable precautions to ensure that any attachment to this email has been swept for viruses. However, we cannot accept any liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer system may be viewed by other Retail Decisions employees or officers strictly in accordance with law. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Index problem
Kafsat, Can you post the Dictionary Item and the BASIC code? - Charles Barouch [EMAIL PROTECTED] kafsat taiyus wrote: We have one Unidata 5.1 data file with a virtual attribute. The virtual dictionary calls a Unibasic subroutine and returns a single value data from a multi value attribute from within the same file. We have an index on the virtual attribute. When new records are added to the file Unidata does not update the index on the virtual attribute. After adding new records that returns XXX for the virtual attribute the command LIST FILE_NAME WITH VIRTUAL_ATT = XXX does not return any record. But the command LIST FILE_NAME NO.INDEX WITH VIRTUAL_ATT = XXX finds the record. The command LIST FILE_NAME WITH VIRTUAL_ATT = XXX works only after rebuilding the index using REBUILD.INDEX command. Do you know why is it happening and how to fix it? Thank you in anticipation. Regards Kafsat --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
