AKIndexKey:@TM:AKIndexRecord
The program them uses this list to populate the index file and does this like:
AKindexKey = field(RowFromSelectList, @TM, 1) AKindexRec = field(RowFromSelectList, @TM, 2,999)
thus if you have an @TM in your AKindexKey your results will be exactly as you see.
I guess you could now call this a bug since when I re-wrote BUILD.INDEX back in 1991 you could not have system delimiters within record keys. With the advent of SQL you could. As a matter of fact, the BUILD.INDEX code actually takes this into account, looking for extra @TM's in your record key IFF you are building an SQL index.
Since you probably have the BUILD.INDEX code (in the BP file of the uvhome account),
look for a line like:
tm.loc=index(item.to.parse,@TM,1)
which should be around line 1240 or so. tm.loc is used to determine the break point in the "item.to.parse" data of the index key and the index data. You could add some logic here to count the number of @TM's then set the break point to the last @TM (assuming you have no @tm's in your data).
You could also change all the @TM's in the BUILD.INDEX code to some other character that you feel would not be used on your system, but any upgrade would wipe that change out.
Hopefully, this helps you in determining a course of action.
Glenn
At 02:13 AM 03/24/2004, you wrote:
Hi all, this one is kinda weird on the one hand but on the other, if it's accepted behaviour, then I can use it for good (not evil). I've created an i-type field on a file:
0001 I me me mine test index field 0002 if F1 then F1:@tm:F2 else '' 00...
-- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
