I've got the results of the traces back and it looks like the Access code is now passing a date bind variable in as something that prevents the proper use of the indexed date column. I say this because when I look at the trace I see the internal_function on the indexed column and when I run the query, with the only modification being adding 0 to the date column I get my bad explain plan. What's perplexing is that everyone claims that there were no changes made. What I know for sure is that there was an upgrade to a new release of the Oracle Windows ODBC driver -- 10.2.0.4 ( supposedly migrated a few weeks prior to our problem start) and that the Oracle statistics collection procedure was changed from a 30% estimate to COMPUTE on the day the problem was first reported. On 8/27/08, Rumpi Gravenstein <rgravens@xxxxxxxxx> wrote: > > <snip> > 10g stores previous version of stats for 30 days by default, you can > revert stats to see if the better performing plans return and if so > you can compare the different versions of the stats and plans to > identify the culprit and correct it. > </snip> > > The queries from the two environments are run within a few minutes of each > other, sometimes the Toad version first and sometimes the Access version. > Each run uses the same, single bind value. Given that I can't see how the > problem can be related to differences in statistics. > > I'll check meta-link for odbc slow-down bugs. > -- Rumpi Gravenstein