We found the issue. As it turns out, the indexes were not being created using NLSSort as we expected. The code to create the indexes included this function but the syntax was a little wrong and rather than erroring out, Oracle decided to fix the syntax and in doing so, dropped the function call on the index. That was a bear to track down... :-) I still don't understand why it appears to work using Access?


>No, I have not read that article. I will do so tonight. I read several other articles regarding the new case sensitive searching and we thought we followed the directions correctely. Maybe we did not. :-)
>
>Thank you again for your help.
>
>>Hmm,
>>
>>I have not oracle on home comp and I cannot test it.
>>Did you read this article?
>>
>>MartinaJ
>>
>>>Thank you so much for your quick reply. I guess that I was not quite clear enough. The same query run from VFP, Access and a Java program will yield different results. For example:
>>>
>>>

SELECT * FROM customer WHERE state = 'OH'

>>>
>>>will use the index in java and Access but a full table scan in FoxPro. In the VFP and Access cases, we are connecting to the database using ODBC and the same DSN.
>>>
>>>
>>>>Hi Toni,
>>>>
>>>>You need the hints
>>>>
>>>>MartinaJ
>>>>
>>>>>Does anyone know what FoxPro is doing with the connection that might induce Oracle to do a table scan rather than use the index? FWIW, we know that this is not a parameter issue because it occurs on JOIN statements as well.
>>>>>
>>>>>Toni-