Actually, I was already considering doing some index consolidation since you mentioned it in your last post, Jeff :-). Scripted out all of the indexes, and ran some tests.

I ended up tossing the Name index, which the system doesn't use anyhow; I use it ad-hoc sometimes if I can't figure out the crazy k_id numbering scheme, which is never really consistent. In fact, after some testing, I found I could actually fling out all of the indexes and just create a single on on ParentID, with Name and Type as INCLUDED columns, and the results seemed to be just about as good as they were before the indexes were dropped.

Now, the really weird thing is that, after I tossed all the duplicate indexes, the reporting side of the app suddenly got quite a bit faster :crazy:. It usually takes about 5 minutes to get through the navigation screens to set up a report, but now it takes maybe a minutes and a half. But removing duplicate indexes shouldn't have done that, right? They only really slow down INSERT and DELETE operations because of the necessity to INSERT and DELETE on each index, if I recall correctly. It doesn't seem like the crazy SELECT operations in the reporting process should have been affected.

Then again, the app does rely on the client's computer, rather than the server, for all of the heavy lifting, so that just confounds the issue further :w00t:. I'll ask the users to try it and see if they notice any improvements.

Thanks for the pointers, Jeff! I'd been considering doing some index consolidation here, and having someone affirm my thoughts makes me feel a little less novice-y.