>>Oddly, I ended up with the 3-character limit myself on a half million record table where the users were searching for all matches. It was a compromise with the users wanting 2, but they didn't like the delay.
>
>Excatly, after all, with a million records table, what need can there be to have a subset with only the first letter or first 2 characters. Also, even if we let the user to type one or 2 characters, they will still have to precise their search. So, it's just a way of doing things. I have the same here on the Universal Thread.
Michel started thread with ? about grid vs brow.
I did some testing and I did not find difference in their behavior.
What I found:
It seems that (as Dave Johns said earlier) brow shows you results as soon it finds enough records to fill whole window. It does not matter, how many characters in your filter, 2 or 20.
What does matter, how many records from table will meet this criteria, where they are ( maybe all of them at the top and you are lucky) and how many records fit into your brow window (i.e. how big this window) .
That means, that filter to "ABCDEF" can take 1 sec and filter to "B" 10 sec, if you have more records with "ABCDEF" than with "B". Same filter will work faster if you use smaller brow window, because it stops looking faster. Try this: BROW, then resize window and BROW LAST. You’ll see difference.
From what I saw, GRID works in same manner, but I just started Visual programming and not sure about it. So, it might be that we compare big GRID window with small BROW window?
HIH
Oleg