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/
