Ben and Marc,
parens around the whole condition or a group of conditions can affect the
order of indexes. However, to force the non-usage of an index, don't
parenthicate the whole condition, just the value to the right of the
operator. That way you turn the value into an expression, and R:BASE figures
it needs to evaluate it for each row. That would be t_1.tr_type = ('1')
Bill
On Fri, May 8, 2009 at 9:23 AM, Ben Petersen <[email protected]>wrote:
> Hi Marc,
>
> I'm looking at
>
> > (t_1.tr_type = '1') AND
>
> I don't recall -- do parens force usage of an index, or the reverse?
> Regardless, you might try w/o them.
>
> Is tr_type actually a string data type (single quotes)?
>
> I understand that the main question is why it takes twice as long
> under v8 to print the report, but one thought might be to limit the
> data, either in the view or the where clause for the report.
>
> So
> > WHERE +
> > (t_1.tr_type = '1') AND +
>
> might become something like
>
> > WHERE +
> dr_num = 1234 and +
> > (t_1.tr_type = '1') AND +
>
> Assuming dr_num (or what ever limiting data) is indexed, and early in
> the where clause, the report should start pretty quickly.
>
>
>
> > If the report is based off a view why
> > does it access the individual tables?
>
> Someone mentioned earlier that a view is just a stored Sql Query,
> there is no data stored in a view. They are also referred to as
> "pseudo tables" because, just like this report, you can refer to a Sql
> Query as though it is a table. Of course you can stack one view on top
> of another if need be. So views are just a convenient way for
> referring to/using queries.
>
> Since selecting against this view is as fast as it was under 7.5
> (that's correct??) I think the suggestions referring to settings in
> the report itself make the most sense. If your view construct was
> faulty I would think performance would be poor under both platforms.
>
>
> Ben
>
>
>
