RE: [U2] UV: Indexing I-Descriptors
In order to get the customer name we translate into the address book. Now Hence, you've got two unsynchronized indexes. That's the problem noted. I don't believe U2 has an internal function to resolve this situation. First off, I know that IBM doesn't support translates in indexes .. I know for a fact that it doesn't work on UV - you build the index, and it *SEEMS* to be OK, but all updates after that essentially produce a blank entry in the index, since all NEW records don't actually exist when the initial index update (and therefore initial translate) are done .. I suppose that if you wrote the record initially (blank index key) and then later updated the record without updating the translated data, the index would fix itself .. The index still doesn't consistently work this way, so you can't really use it .. /$.02 -chuck --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UV: Indexing I-Descriptors
On Fri, 2004-09-17 at 10:40, Glenn Herbert wrote: Exactly how does the SELECT fail? 0 items returned? hang? crash? Zero items... In this application, one person purchases based on invoiced items. however, if this particular item isn't working, quotes go into the purchasing screen, thus causing items only quoted to clients being ordered. Not a good thing. The syntax that was failing was standard enough (DICT=TYPE, 3=Quote): STMT = 'SELECT BKORD WITH F26 = AND F10 0' STMT := ' AND F01 = N AND TYPE # 3' STMT := ' AND F02 = ':WHOUSENO:' BY VENDNAME BY NAME BY @ID' EXECUTE STMT CAPTURING NOTHING -- Karl L. Pearson Director of IT, ATS Industrial Supply Direct: 801-978-4429 Toll-free: 888-972-3182 x29 Fax: 801-972-3888 http://www.atsindustrial.com [EMAIL PROTECTED] Here's the I-Desc again: 0001 I 0002 TRANS(BOHDR,(ORDER.NUMBER),'5','X') 0003 0004 ORD?TYP 0005 2R 0006 S --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UV: Indexing I-Descriptors
On Fri, 2004-09-17 at 11:10, Karjala Koponen wrote: Karl, TRANS I descriptors are dangerous to index. This should work fine when field 5 of BOHDR exists when the record you're going from is written and field 5 of BOHDR does not change. I don't know whether the I descriptor will be reviewed/renewed when the record you're going from is rewritten, but I'd want absolute confirmation that the indexing process does that. I'd be very nervous (assume) that the I descriptor is NOT looked at again at a rewrite. The index will certainly be incorrect, however, when the field 5 of BOHDR is changed after the record you're going from was last written because there is no reason for the index to be updated. Triggers might be used to update the index in such an event but I'd look for help elsewhere on this list for such guidance. Okay, I'll bite... What you say leads me to believe that a TRANS I-Desc is dangerous because if the data changes in the remote file, then the index isn't updated and the data in the local file's index is out-dated, right? if that's the case, then doesn't that mean that the local file's index is holding all the data that is 'TRANS'ed from the other file? Isn't that NOT how an index works? I thought it just pointed to the attribute in the other file where it could look that data up. OR, is it that the stored procedure (TRANS I-Desc) might become different from the remote file's procedure if that DICT item is re-written/changed/removed, etc. ??? I'm a bit confused and would like some clarification... Perhaps what I've understood all these years has been superseded somehow/where. KLP Karjala [EMAIL PROTECTED] 09/17/2004 11:49:42 AM I just had an experience (UV 10.0.14, AIX 4.3.3) of indexing an I-Descripted DICT item and than having a very important routine fall down. Selecting against the TYPE I-Desc fails after being indexed and doesn't before. I seem to remember a bug in this but hoped the bug had been solved... Here's the I-Desc: 0001 I 0002 TRANS(BOHDR,(ORDER.NUMBER),'5','X') 0003 0004 ORD?TYP 0005 2R 0006 S 0007... DELETED Another thought: Is there a problem right justifying? Should it be left (counter-intuitive from my perspective)? -- Karl L. Pearson Director of IT, ATS Industrial Supply Direct: 801-978-4429 Toll-free: 888-972-3182 x29 Fax: 801-972-3888 http://www.atsindustrial.com [EMAIL PROTECTED] --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UV: Indexing I-Descriptors
yes - the index is evaluated at the time it is created and any time the record changes. other than that it is static data that is stored as the 'key' in the index file itself which then points to the @ID of the indexed file. - Original Message - From: Karl L Pearson [EMAIL PROTECTED] To: u2-users [EMAIL PROTECTED] Sent: Friday, September 17, 2004 02:11 pm Subject: Re: [U2] UV: Indexing I-Descriptors On Fri, 2004-09-17 at 11:10, Karjala Koponen wrote: Karl, TRANS I descriptors are dangerous to index. This should work fine when field 5 of BOHDR exists when the record you're going from is written and field 5 of BOHDR does not change. I don't know whether the I descriptor will be reviewed/renewed when the record you're going from is rewritten, but I'd want absolute confirmation that the indexing process does that. I'd be very nervous (assume) that the I descriptor is NOT looked at again at a rewrite. The index will certainly be incorrect, however, when the field 5 of BOHDR is changed after the record you're going from was last written because there is no reason for the index to be updated. Triggers might be used to update the index in such an event but I'd look for help elsewhere on this list for such guidance. Okay, I'll bite... What you say leads me to believe that a TRANS I-Desc is dangerous because if the data changes in the remote file, then the index isn't updated and the data in the local file's index is out-dated, right? if that's the case, then doesn't that mean that the local file's index is holding all the data that is 'TRANS'ed from the other file? Isn't that NOT how an index works? I thought it just pointed to the attribute in the other file where it could look that data up. OR, is it that the stored procedure (TRANS I-Desc) might become different from the remote file's procedure if that DICT item is re-written/changed/removed, etc. ??? I'm a bit confused and would like some clarification... Perhaps what I've understood all these years has been superseded somehow/where. KLP Karjala [EMAIL PROTECTED] 09/17/2004 11:49:42 AM I just had an experience (UV 10.0.14, AIX 4.3.3) of indexing an I-Descripted DICT item and than having a very important routine fall down. Selecting against the TYPE I-Desc fails after being indexed and doesn't before. I seem to remember a bug in this but hoped the bug had been solved... Here's the I-Desc: 0001 I 0002 TRANS(BOHDR,(ORDER.NUMBER),'5','X') 0003 0004 ORD?TYP 0005 2R 0006 S 0007... DELETED Another thought: Is there a problem right justifying? Should it be left (counter-intuitive from my perspective)? -- Karl L. Pearson Director of IT, ATS Industrial Supply Direct: 801-978-4429 Toll-free: 888-972-3182 x29 Fax: 801-972-3888 http://www.atsindustrial.com [EMAIL PROTECTED] --- 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/
