Bernie, Ah, but you knew what it meant, didn't you? Didn't you!? Bill
On Fri, May 8, 2009 at 4:16 PM, Bernard Lis <[email protected]> wrote: > Your search - *parenthicate* - did not match any documents. > > Suggestions: > > - Make sure all words are spelled correctly. > - Try different keywords. > - Try more general keywords. > > ----- Original Message ----- > *From:* Bill Downall <[email protected]> > *To:* RBASE-L Mailing List <[email protected]> > *Sent:* Friday, May 08, 2009 9:30 AM > *Subject:* [RBASE-L] - Re: 7.5 vs V8 speed > > 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 >> >> >> >
