>>The way I was building those keys meant adding an additional character for each level, and using A, B, C etc within the same level, so a node which would be denoted as 3.1.5.3 would have a key of CAEC; this works fine as long as you don't have too many values within the same level and not too many levels.
>>
>>In message threading, the number of records within the same level (i.e. messages which are replies to the same message) is quite unpredictable, and so is the number of levels (length of the message-response-response-... chain). Using such a key would probably require more than one character, and with the limitation on the total length of a key, you couldn't do more than 120 levels deep.
>
>I do not use that approach. I only use a NoParent field in the cursor. Each node ID is based on the message ID, for example, and that's fixed. So, for those not having a parent, they consititute the top branch. Than, the recursive loop is starting.

I agree that this approach is far better for your data. Just maintaining that key would slow you down enough to outweigh the benefits. To adapt the approach I was using there, you'd have to have an index on NoThread+cKeyField, where the cKeyField would have one or two characters per level. I think you've already had threads which went more than 255 levels deep, so my bet would be that you'd need two chars. OTOH, if you could get this to work with your data, you'd have the treeview drawn in a single pass, without recursion. You'd only have to build the key when saving a new message, but you could rely on the previous key being already built, so you wouldn't have to recurse at all, just bring all the previous replies to the same message to find out the last key used for that level, increase the last character by one, and that's it. You wouldn't have to recurse at all.

The only question is the capacities of your data engine - can it sort by a field of the necessary length.