Re: [U2] Unidata 7.1.22 Index Issue
This information has been extremely helpful! I had 11 files have the indexes go bad on them, and they needed to be completely rebuilt. The only anomaly is that the DELETE.INDEX fn ALL didn't work right away. There was an index on the file, a V-field, called XERP.SQLTRIG. When the index went bad, it was there, but not really there. On a file called STUMAST for example, I would say: :LIST.INDEX STUMAST No indices created on file STUMAST : Then I would say try to create the index: :CREATE.INDEX STUMAST XERP.SQLTRIG XERP.SQLTRIG: can not create multiple indices on same location No new indices are created : So UniData sort of knows the index was there, but it doesn't really know. And unfortunately, that is my problem. I tried to delete it: DELETE.INDEX STUMAST ALL No indices created on file STUMAST : And the create index would fail again. So what I did was create another index, I actually indexed @ID, then the DELETE.INDEX STUMAST ALL did work, and I was able to re-install my original XERP.SQLTRIG index. So, basically, by creating (I did not actually have to build) a bogus index and then doing the DELETE.INDEX fn ALL it did solve my problem. Is this a UniData bug or two that might be looked into by any chance? :-) (I saw my issue on UniData 7.2.2 for Windows) Thanks! Steve... -- Steve Kneizys ERPData, LLC Ferrilli Information Group -Original Message- From: Wally Terhune wterh...@rocketsoftware.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Fri, Sep 9, 2011 7:36 pm Subject: Re: [U2] Unidata 7.1.22 Index Issue NO. was mostly trying to point out that you need to be specific about what perations you have done regarding index refreshing. 'rebuild' is unspecific. For logical integrity issues - which generally occur because folks create ndexes that depend on another file to get the virtual field index value (such s via TRANS, or OCONV(TFILENAME,...)) - you can just BUILD.INDEX on one or more r all indexed fields in a file. If you don't use the ONLINE keyword, users rying to update the primary file will hang until the build is done (or will not tart if it cannot get exclusive update access on the primary file). If you have physical corruption to the index file (rare), you need to completely emove the index file (by using the ALL keyword with DELETE.INDEX). Then REATE.INDEX, then BUILD.INDEX. If you run multiple DELETE.INDEX commands naming ields - until none are left - the index file is still there and may still ontain some physical corruption. You can see if you have either logical or physical corruption by running uide_ndx. You can check for both using the -x3,all option. Then look at UIDE_XERROR.LIS output file. Note - guide_ndx does not block updates to the ile (as BUILD.INDEX without the ONLINE keyword does), so you can get spurious ogical errors if the file is being actively updated when you run it. If you aren't sure and don't want to check, the cleanest steps are: ) get exclusive access to the file ) DELETE.INDEX fn ALL ) CREATE.INDEX fn field1 field2, etc ) BUILD.INDEX fn ALL (this is quicker than individual BUILD.INDEX commands on ultiple fields as there is only one pass thru the primary file to create the MP records used to create the index nodes). More confused, now? :-( Wally Terhune 2 Support Architect ocket Software 600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA el: +1.720.475.8055 mail: wterh...@rs.com eb: www.rocketsoftware.com/u2 -Original Message- rom: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] n Behalf Of Kevin King ent: Friday, September 09, 2011 5:20 PM o: U2 Users List ubject: Re: [U2] Unidata 7.1.22 Index Issue Am I understanding you correctly Wally that if an index becomes corrupted or any reason the index is to be deleted, then recreated, and THEN rebuilt? And in a related question, am I understanding you to say that an index annot (should not) be rebuilt without being deleted and recreated? __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
Were these files by any chance copied/moved from their original location? The headers to the file, (at least in Universe), create pointers to the physical disk location of the indexes, and if you move the file without adjusting those pointers, you can have all sorts of fun issues. On 10/13/2011 10:07 AM, regalit...@aol.com wrote: This information has been extremely helpful! I had 11 files have the indexes go bad on them, and they needed to be completely rebuilt. The only anomaly is that the DELETE.INDEX fn ALL didn't work right away. There was an index on the file, a V-field, called XERP.SQLTRIG. When the index went bad, it was there, but not really there. On a file called STUMAST for example, I would say: :LIST.INDEX STUMAST No indices created on file STUMAST : Then I would say try to create the index: :CREATE.INDEX STUMAST XERP.SQLTRIG XERP.SQLTRIG: can not create multiple indices on same location No new indices are created : So UniData sort of knows the index was there, but it doesn't really know. And unfortunately, that is my problem. SNIP ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
We came across this a few years back when moving and copying files at the OS level (usually copying the data file but not the associated index). What's even easier than creating a dummy index (especially on a large file) is to simply copy another files index (X_smallfilename) to your working file (X_STUMAST). Then you can do the DELETE.INDEX STUMAST ALL. hth Colin Alfke Calgary, Canada -Original Message- From: regalit...@aol.com This information has been extremely helpful! I had 11 files have the indexes go bad on them, and they needed to be completely rebuilt. The only anomaly is that the DELETE.INDEX fn ALL didn't work right away. There was an index on the file, a V-field, called XERP.SQLTRIG. When the index went bad, it was there, but not really there. On a file called STUMAST for example, I would say: :LIST.INDEX STUMAST No indices created on file STUMAST : Then I would say try to create the index: :CREATE.INDEX STUMAST XERP.SQLTRIG XERP.SQLTRIG: can not create multiple indices on same location No new indices are created : So UniData sort of knows the index was there, but it doesn't really know. And unfortunately, that is my problem. I tried to delete it: DELETE.INDEX STUMAST ALL No indices created on file STUMAST : And the create index would fail again. So what I did was create another index, I actually indexed @ID, then the DELETE.INDEX STUMAST ALL did work, and I was able to re-install my original XERP.SQLTRIG index. So, basically, by creating (I did not actually have to build) a bogus index and then doing the DELETE.INDEX fn ALL it did solve my problem. Is this a UniData bug or two that might be looked into by any chance? :-) (I saw my issue on UniData 7.2.2 for Windows) Thanks! Steve... ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
They very well may have been. A resize is performed periodically by the admins there as needed. Thinking back, the sizes on the were all large, I remember a couple of them being 13 modulo, I think somebody did up the size quite a bit. I wonder if a UniData resize or memresize would do it if combined with a live system (not a guarantee of exclusivity.) I know even on UniData 7.1 the folks helping with system admin tasks like resizes and such would do it while folks were online and using these files (I kind of freaked out about that...) -Original Message- From: Allen Egerton aeger...@pobox.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Oct 13, 2011 10:21 am Subject: Re: [U2] Unidata 7.1.22 Index Issue Were these files by any chance copied/moved from their original location? The headers to the file, (at least in Universe), create pointers to the hysical disk location of the indexes, and if you move the file without djusting those pointers, you can have all sorts of fun issues. n 10/13/2011 10:07 AM, regalit...@aol.com wrote: This information has been extremely helpful! I had 11 files have the indexes go bad on them, and they needed to be ompletely rebuilt. The only anomaly is that the DELETE.INDEX fn ALL didn't work right away. There was an index on the file, a V-field, called XERP.SQLTRIG. When the ndex went bad, it was there, but not really there. On a file called STUMAST for xample, I would say: :LIST.INDEX STUMAST No indices created on file STUMAST : Then I would say try to create the index: :CREATE.INDEX STUMAST XERP.SQLTRIG XERP.SQLTRIG: can not create multiple indices on same location No new indices are created : So UniData sort of knows the index was there, but it doesn't really know. And unfortunately, that is my problem. SNIP __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
You may have a problem with leading zeroes. Are there by any chance 2 records with 9 in Record120,2? On 09/09/2011 04:08, Kevin King wrote: What can I get you Wally? We did a CREATE.INDEX WO SHOP.CODE NO.NULLS followed by BUILD.INDEX WO SHOP.CODE. The index seems to work fine immediately after. If the shop code in the record changes, however, the index does not seem to reflect the change. This is evidenced by: DISABLE INDEX WO SELECT WO WITH SHOP.CODE = 09 21 items selected CLEARSELECT ENABLE.INDEX WO SELECT WO WITH SHOP.CODE = 09 19 items selected CLEARSELECT DISABLE.INDEX WO SELECT WO WITH SHOP.CODE = 09 21 items selected What else can I get you? On Thu, Sep 8, 2011 at 5:58 PM, Wally Terhune wterh...@rocketsoftware.comwrote: Not enough information. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 5:42 PM To: U2 Users List Subject: [U2] Unidata 7.1.22 Index Issue We have a customer on Unidata 7.1.22 running the Prelude application. They have an index on a field in a file that looks like this: Top of SHOP.CODE in DICT WO, 9 lines, 82 characters. *--: P 001: V 002: EXTRACT(@RECORD,110,2,0) 003: 004: Shop Code 005: 2L 006: S 007: 008: SHOP.CODEýýEXTRACT(@RECORD,110,2,0) 009: WO Bottom. Because this field is extracting from @RECORD, we should be able to index it without problems, right? However, the reality is starkly different. The other data indexes work fine, but this derived index does not seem to be getting updated properly. -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
Kevin: The things you need to review: 1) LIST.INDEX WO ALL DETAIL - to examine the index definitions and details of keys in the file 2) From the shell, without the file being updated: guide_ndx -x3,all WO Review the output file GUIDE_XERROR.LIS for physical or logical corruption 3) UDT.OPTIONS active (per Mecki's comment about leading 0s) Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 9:09 PM To: U2 Users List Subject: Re: [U2] Unidata 7.1.22 Index Issue What can I get you Wally? We did a CREATE.INDEX WO SHOP.CODE NO.NULLS followed by BUILD.INDEX WO SHOP.CODE. The index seems to work fine immediately after. If the shop code in the record changes, however, the index does not seem to reflect the change. This is evidenced by: DISABLE INDEX WO SELECT WO WITH SHOP.CODE = 09 21 items selected CLEARSELECT ENABLE.INDEX WO SELECT WO WITH SHOP.CODE = 09 19 items selected CLEARSELECT DISABLE.INDEX WO SELECT WO WITH SHOP.CODE = 09 21 items selected What else can I get you? On Thu, Sep 8, 2011 at 5:58 PM, Wally Terhune wterh...@rocketsoftware.comwrote: Not enough information. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 5:42 PM To: U2 Users List Subject: [U2] Unidata 7.1.22 Index Issue We have a customer on Unidata 7.1.22 running the Prelude application. They have an index on a field in a file that looks like this: Top of SHOP.CODE in DICT WO, 9 lines, 82 characters. *--: P 001: V 002: EXTRACT(@RECORD,110,2,0) 003: 004: Shop Code 005: 2L 006: S 007: 008: SHOP.CODEýýEXTRACT(@RECORD,110,2,0) 009: WO Bottom. Because this field is extracting from @RECORD, we should be able to index it without problems, right? However, the reality is starkly different. The other data indexes work fine, but this derived index does not seem to be getting updated properly. -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
Thanks Wally. In this situation we suspect that the index was rebuilt while some users had the file open (via SB+ cached file buffers) and those users were the ones entering transactions that didn't get updated into the index. We logged everyone off last night and rebuilt the index and so far today things appear to be better. On Fri, Sep 9, 2011 at 6:30 AM, Wally Terhune wterh...@rocketsoftware.comwrote: Kevin: The things you need to review: 1) LIST.INDEX WO ALL DETAIL - to examine the index definitions and details of keys in the file 2) From the shell, without the file being updated: guide_ndx -x3,all WO Review the output file GUIDE_XERROR.LIS for physical or logical corruption 3) UDT.OPTIONS active (per Mecki's comment about leading 0s) Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 9:09 PM To: U2 Users List Subject: Re: [U2] Unidata 7.1.22 Index Issue What can I get you Wally? We did a CREATE.INDEX WO SHOP.CODE NO.NULLS followed by BUILD.INDEX WO SHOP.CODE. The index seems to work fine immediately after. If the shop code in the record changes, however, the index does not seem to reflect the change. This is evidenced by: DISABLE INDEX WO SELECT WO WITH SHOP.CODE = 09 21 items selected CLEARSELECT ENABLE.INDEX WO SELECT WO WITH SHOP.CODE = 09 19 items selected CLEARSELECT DISABLE.INDEX WO SELECT WO WITH SHOP.CODE = 09 21 items selected What else can I get you? On Thu, Sep 8, 2011 at 5:58 PM, Wally Terhune wterh...@rocketsoftware.comwrote: Not enough information. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 5:42 PM To: U2 Users List Subject: [U2] Unidata 7.1.22 Index Issue We have a customer on Unidata 7.1.22 running the Prelude application. They have an index on a field in a file that looks like this: Top of SHOP.CODE in DICT WO, 9 lines, 82 characters. *--: P 001: V 002: EXTRACT(@RECORD,110,2,0) 003: 004: Shop Code 005: 2L 006: S 007: 008: SHOP.CODEýýEXTRACT(@RECORD,110,2,0) 009: WO Bottom. Because this field is extracting from @RECORD, we should be able to index it without problems, right? However, the reality is starkly different. The other data indexes work fine, but this derived index does not seem to be getting updated properly. -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
If a user has a file open and there is no index created on the file, if another user creates an index on the file - the first user will not know that an index has been created (and the bit in the primary file header updated to indicate that - the number of indexes on the file). So updates to the file will not update the index until that first user closes and reopens the file. Characteristics about the file are stored in a udt's process private memory when the process first opens the file (inode/dnode, index count, etc). In terms of building... There is BUILD.INDEX ONLINE that can be used to build while users have the file open - assuming they already know there are indexes created (whether or not they are built). So (in general) - when you say 'rebuilt', you need to be specific about the steps taken. DELETE.INDEX WO ALL? CREATE.INDEX WO FIELD1 FIELD2? BUILD.INDEX WO ALL? Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Friday, September 09, 2011 11:57 AM To: U2 Users List Subject: Re: [U2] Unidata 7.1.22 Index Issue Thanks Wally. In this situation we suspect that the index was rebuilt while some users had the file open (via SB+ cached file buffers) and those users were the ones entering transactions that didn't get updated into the index. We logged everyone off last night and rebuilt the index and so far today things appear to be better. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
Am I understanding you correctly Wally that if an index becomes corrupted for any reason the index is to be deleted, then recreated, and THEN rebuilt? And in a related question, am I understanding you to say that an index cannot (should not) be rebuilt without being deleted and recreated? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
NO. I was mostly trying to point out that you need to be specific about what operations you have done regarding index refreshing. 'rebuild' is unspecific. For logical integrity issues - which generally occur because folks create indexes that depend on another file to get the virtual field index value (such as via TRANS, or OCONV(TFILENAME,...)) - you can just BUILD.INDEX on one or more or all indexed fields in a file. If you don't use the ONLINE keyword, users trying to update the primary file will hang until the build is done (or will not start if it cannot get exclusive update access on the primary file). If you have physical corruption to the index file (rare), you need to completely remove the index file (by using the ALL keyword with DELETE.INDEX). Then CREATE.INDEX, then BUILD.INDEX. If you run multiple DELETE.INDEX commands naming fields - until none are left - the index file is still there and may still contain some physical corruption. You can see if you have either logical or physical corruption by running guide_ndx. You can check for both using the -x3,all option. Then look at GUIDE_XERROR.LIS output file. Note - guide_ndx does not block updates to the file (as BUILD.INDEX without the ONLINE keyword does), so you can get spurious logical errors if the file is being actively updated when you run it. If you aren't sure and don't want to check, the cleanest steps are: 1) get exclusive access to the file 2) DELETE.INDEX fn ALL 3) CREATE.INDEX fn field1 field2, etc 4) BUILD.INDEX fn ALL (this is quicker than individual BUILD.INDEX commands on multiple fields as there is only one pass thru the primary file to create the TMP records used to create the index nodes). More confused, now? :-( Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Friday, September 09, 2011 5:20 PM To: U2 Users List Subject: Re: [U2] Unidata 7.1.22 Index Issue Am I understanding you correctly Wally that if an index becomes corrupted for any reason the index is to be deleted, then recreated, and THEN rebuilt? And in a related question, am I understanding you to say that an index cannot (should not) be rebuilt without being deleted and recreated? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
Not enough information. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 5:42 PM To: U2 Users List Subject: [U2] Unidata 7.1.22 Index Issue We have a customer on Unidata 7.1.22 running the Prelude application. They have an index on a field in a file that looks like this: Top of SHOP.CODE in DICT WO, 9 lines, 82 characters. *--: P 001: V 002: EXTRACT(@RECORD,110,2,0) 003: 004: Shop Code 005: 2L 006: S 007: 008: SHOP.CODEýýEXTRACT(@RECORD,110,2,0) 009: WO Bottom. Because this field is extracting from @RECORD, we should be able to index it without problems, right? However, the reality is starkly different. The other data indexes work fine, but this derived index does not seem to be getting updated properly. -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 7.1.22 Index Issue
What can I get you Wally? We did a CREATE.INDEX WO SHOP.CODE NO.NULLS followed by BUILD.INDEX WO SHOP.CODE. The index seems to work fine immediately after. If the shop code in the record changes, however, the index does not seem to reflect the change. This is evidenced by: DISABLE INDEX WO SELECT WO WITH SHOP.CODE = 09 21 items selected CLEARSELECT ENABLE.INDEX WO SELECT WO WITH SHOP.CODE = 09 19 items selected CLEARSELECT DISABLE.INDEX WO SELECT WO WITH SHOP.CODE = 09 21 items selected What else can I get you? On Thu, Sep 8, 2011 at 5:58 PM, Wally Terhune wterh...@rocketsoftware.comwrote: Not enough information. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 5:42 PM To: U2 Users List Subject: [U2] Unidata 7.1.22 Index Issue We have a customer on Unidata 7.1.22 running the Prelude application. They have an index on a field in a file that looks like this: Top of SHOP.CODE in DICT WO, 9 lines, 82 characters. *--: P 001: V 002: EXTRACT(@RECORD,110,2,0) 003: 004: Shop Code 005: 2L 006: S 007: 008: SHOP.CODEýýEXTRACT(@RECORD,110,2,0) 009: WO Bottom. Because this field is extracting from @RECORD, we should be able to index it without problems, right? However, the reality is starkly different. The other data indexes work fine, but this derived index does not seem to be getting updated properly. -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
