>Computed columns get computed on select, if they are in the specified
>output set. Computed columns that use subqueries are expensive, whatever
>way you look at them.

Yeah, I guess you're right. I actually have FetchWholeRows set to
FALSE. So, in this case, I believe they are NOT computed when I open the
table, but when I scroll to each record. That's why there's the delay when
scrolling. In order to eliminate the scrolling delay, I think I'd have to
set FetchWholeRows to TRUE, and in that case, there would be a HUGE delay
as soon as I open the table. So, it's a tradeoff. I have to pay the price
SOMETIME. Even if I limited the output to 200 rows at a time, it would
still have to compute 200 values every so often.

>Use a TIBOQuery instead and don't included the computed column in the
>output of your main set. Also -- watch the size of output sets!!! Always
>use a parameterised WHERE clause to limit the output to 200 rows or less.
>
>To show the computed column for the current row only, add another query
>(parameterised) containing just the primary key and the computed column,
>with a 1:1 detail-master relationship to the main query.

Doing this didn't actually help with the scrolling delay, as long as the
detail query was open (I believe for the reasons that I stated above), but
it DID help me in another way.

I added a button to my form to show/hide the computed column. By default,
the detail query w/ the computed column is closed, which hides the value of
that column. If the user wants to see the column, they click "Show", my
app opens the detail query, the computed column is populated, and the
scrolling is slow. If they want faster scrolling, they can click "Hide",
which closes the detail query, and speeds up the scrolling.

Thanks!

-Joe