Agree on this one. Anyway, I designed a grid class that does index/order stuff transparently. After temporary index is created, Subsequent reordering is instantaneous, no matter how many rows the result set has.

Well, personally, I agree, because I've done this as well - wrote something generic in a VFP grid to automatically create a tag on every column. This is a good example of writing something generic as a functional equivalent of another tool's capabilities, and I'm fine with that.

However, when I've mentioned in the past that I've written some generic equivalents in .NET (like a generic LOCATE and other functions), the responses have always been along the lines of "it's going to be slower", "you're introducing more code, and it's not likely to be standard, it increases the risk of bugs".

While I don't regard those responses as completely without merit, in the context they were basically "knee-jerk" reactions. Why is it considered acceptable to write a good functional equivalent in one tool, but not in another tool? (I'm not asking you specifically).

On the random delays, it might have been garbage collection, I'm not sure. Have you tried it in VS2005? Reason I'm asking, they rewrote the ADO engine under the hood.

Thanks,
Kevin