Colin: The dictionary is virtual. It's code is:
002: OCONV( CLIENTNO, 'MR%4' ) : YRMO_PSTD : OCONV( ACCTNO, 'MR%6' ) : OCONV( @ID, 'MR%8' ) CLIENTNO, YRMO_PSTD, and ACCTNO are [D]irect dictionaries with no conversions (just raw data). How does one go about testing if indexing is used in a query? I'm sure it's not, for this query, because of the time differences between D3 (on an old P-III) and UD (on a new Xeon); D3 being much faster on an index select. The output looks like: 060520030800307000583056 When I use a SETINDEX, READXFWD, READXBCK in BASIC I get to the top and bottom instantaneously. So, I'm thinking a SELECT using the index should also be almost instantaneous for such a relatively small number of items. Thanks, Bill >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >[EMAIL PROTECTED] >Sent: Wednesday, August 15, 2007 10:00 PM >To: [email protected] >Subject: {Blocked Content} RE: [U2] UD: Using indexes in UniQuery > >Warning: This message has had one or more attachments removed >Warning: (not named). >Warning: Please read the "AngelicHost-Attachment-Warning.txt" >attachment(s) >for more information. > >Bill; > >Any chance that any of the parts of the index are translated or does a >subroutine call? > >I always had more trouble with D3 indices than with UD. We >don't use sort.type >2 though. A quick test showed no difference though. I also >liked the thought >that it may be trying to use a pattern match than a string. > >HTH >Colin Alfke >Calgary Canada > >________________________________ > >From: Bill Haskett > > >>> >>>I forgot to add: >>> >>>UD v7.1.9 >>>SORT.TYPE = 2 (forced to do this because of improper sorting in >>>SORT.TYPE 0) >>> >>>Bill >>> _____ >>> >>>From: Bill Haskett >>Sent: Wednesday, August 15, 2007 12:25 PM >>> >>>I'm having difficulty ensuring the indexes are used in UniQuery. In >>>D3, if I do the >>>following: >>> >>>26 Demo (0)-> SELECT GLPOST WITH INDEX_2 = "0605]" >>> >>>[4041] 21791 items selected. >>> >>>...it would always use the index if one existed. I knew the >>index was >>>used because the selected message didn't include the " out of {n} >>>items." string appended to the end (e.g. "[404] 21791 items selected >>out of 884083 items."). >>> >>>On an old P3 server, running D3, with 50 people on it, 512Mb memory >>>(shared by Linux), this took about 9 seconds. On a new Intel Xeon >>>server, running UniData, >>with >>>5 people on it, 2Gb memory, Windows 2K3, this took about 19 seconds. >>> >>>In UniData, I notice some selects are taking significantly >>longer than >>>in D3. I've properly indexed the file, I can test that >>indexing works >>>by using a BASIC program than does the usual SETINDEX, READXFWD, >>>READXBCK, etc. The index looks >>>like: >This is a message from the MailScanner E-Mail Virus Protection Service >---------------------------------------------------------------------- >The original e-mail attachment "winmail.dat" >was believed to be infected by a virus and has been replaced >by this warning >message. > >If you wish to receive a copy of the *infected* attachment, please >e-mail helpdesk and include the whole of this message >in your request. Alternatively, you can call them, with >the contents of this message to hand when you call. > >At Wed Aug 15 21:46:42 2007 the virus scanner said: > Could not parse Outlook Rich Text attachment > >Note to Help Desk: Look on the AngelicHost MailScanner in >/home/virtual/site2/fst/var/spool/mail.quarantine/20070815 (message >l7G4kcx4003633). >-- >Postmaster >MailScanner thanks transtec Computers for their support >------- >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/
