Colin: None of our indexes work with UniQuery. Most of our indexes, like yours, were designed on D3 and, thus, are multi-key, so to speak. The interesting point is none of our four new installations of UD (and our converted software and data) works with UniQuery against indexes.
The indexes work correctly in BASIC so I know the index is built properly (I've deleted and rebuilt the index, made sure the "X_GLPOST" file was gone (it was), several times). I'm thinking it could be with the UDT.OPTIONS. I've contacted IBM on this and after some false starts I finally got to someone who tested this out. They couldn't reproduce the errors so they called me. After further review I indicated I suspected, since all of our installations were having this problem, UDT.OPTIONS. I gave IBM the UDT.OPTIONS I set and when they set them they were able to reproduce the same problem. I've discovered the issue surfaces when setting UDT.OPTIONS 69 ON and SORT.TYPE to a non-zero value. If I set UDT.OPTIONS 69 OFF, then I can keep SORT.TYPE to a non-zero value (I use 2). So, it seems UniQuery really doesn't use the indexes when UDT.OPTIONS 69 ON and SORT.TYPE is non-zero. We should figure out some kind of resolution. Thanks, Bill >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >[EMAIL PROTECTED] >Sent: Thursday, August 30, 2007 8:51 PM >To: u2-users@listserver.u2ug.org >Subject: {Blocked Content} RE: [U2] UD indexes and UniQuery - redux > >Bill; > >We use them all the time. They make a huge difference (especially on the >older, slower systems). > >I don't know about the exact alternate key thing. I use the below format and >it works things come back quickly. It's the other way that doesn't work >(SELECT NAMES WITH INDEX_1 = "[JOHN"). > >It does take longer if there is a large data set to return. > >I just tried it on both UD 6.0.12 and 7.1.5PE. > >Problems I've seen with an index: >1. early 5 version had a bad udtsort.exe and the index was not built properly >2. file being actively updated when the index was built >3. index was created but not actually built. >4. bad characters in the data (not so much a problem with the index) > >Deleting the index (making sure the x_ file is gone in the OS) and recreate >and rebuild has always solved the problems. Note that we don't usually do >"text searches" like this. We generally use the index for client numbers, >timekeepers, fiscal period, invoice etc. Our application started on Pick >before they had indexes so we have our own cross-reference file for text >searches. We also don't have *really* large files. 99% are under the 2GB >threshold and only a handful of clients have anything larger. I think the >largest is around 4-5GB and I use the index on it all the time - really fast. > >Sorry this wasn't much help. >Colin Alfke >Calgary Canada > >________________________________ > >From: Bill Haskett > >I've been having problems getting UniQuery to use defined (and built) indexes >in UniData. IBM has informed me that UniQuery does not use indexes unless the >exact alternate key is used. e.g. > >:SELECT NAMES WITH INDEX_1 = "JOHNS]" > or >:select NAMES WITH INDEX_1 LIKE "JOHNS..." > >...does not use the index. IBM says using: > >:SELECT NAMES WITH INDEX_1 = "JOHNSON, RON" > >...will work. However, this doesn't work on my system (UD v7.1.9). All of my >index testing works fine in UniVerse, i.e. Retrieve selections use the defined >indexes and returns all selects immediately. > >Does UniQuery use indexes in UniData? > >Thanks, > >Bill ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
