Hello.
I have turned on rushmore level messages using sus(3054,1).
I run the following from the command window:
select * from ruginv where status = "ST000"
ruginv does have an index tag on status.
The response I am getting is that rushmore optimization level is NONE.
I have set optimize on.
Why is this query not optimized
Thanks,
Aleniko
Why this SQL select command is not optimized?
Hot Topic
- Command Window History
- Mongolian language and VFP 9
- my SQL passthrough problem
- scroll bars in editboxes
- newKey() method not found
- OWC11.PivotTable
- HOW TO ADD AUTOMATICALLY A LOT OF .dbf FILE INTO A DATABASE .dbc FILE ???
- Export data to text- How I can bypass the default text delimitter?
- Cursor help
- [URGENT] help extracting FoxPro DBF Encrypted fields
Visual FoxPro
- Converting FoxPro application to a SQL server backend
- _urlcombobox problem
- deployment, building exe problem
- Grids are readOnly. How do I put text in them?
- Remote View SQL 2005 REQUERY Puzzle
- report temp file not found
- How to get IP Address on Clien of LAN....? Help me!!!!!!
- Grid Resizing
- word in vfp
- Primary key + delete....
Why this SQL select command is not optimized?
Hifni
I look forward to seeing a repro.
Tamar
Gabriel Lozano-Moran
While SET ENGINEBEHAVIOR can be a quick solution when you need to get old code running in VFP 8 or 9, it is a red flag that you may not be getting accurate results; such queries should always be revisited soon to eliminate the need for SET ENGINEBEHAVIOR and ensure accurate results.
Tamar
Absinthe
Tamar,
Codepage is a problem for us foreigners more I think. When enginebehavior is 90 and codepages match we still get spurious (I don't know its meaning really, weird, unexpected ) results. So I think since we need to write our defensive coding anyway set enginebehavior is a solution rather than a patch.
(When I have time I'll try to supply some reproducing code here or on UT).
Chad Mumford - MSFT
Hi,
what collate sequence have you set for index on status field I think only query using indexes with collate set to 'Machine' will be fully optimized.
David Sadler
Thanks! Merci! Toda! Shukran!
Cok Tesekkur Edrim!!!
At last - a solution. I have began to think that the Fox had become an Ostrich... You saved me from long nights of coding for nothing...
Long live VFP and its very valueable SQL commands!!!
Aleniko
mohsin08
Set enginebehavior to 70. It's likely you have cpcurrent() # cpdbf() problem.
From VFP help:
"
Rushmore Optimization and Code Pages
Visual FoxPro does not use existing character indexes for tables created with a non-current code page. Instead, Visual FoxPro builds temporary indexes to ensure correct results. This can result in non-optimization of SQL or other commands. To prevent this, ensure that the current Visual FoxPro code page returned by CPCURRENT( ) Function matches the table's code page returned by CPDBF( ) Function. This requires either changing the current Visual FoxPro code page, or changing the table's code page. For information about specifying the current Visual FoxPro code page, see Understanding Code Pages in Visual FoxPro. For information about specifying the code page for a table, see How to: Specify the Code Page of a .dbf File. If you cannot change either the Visual FoxPro codepage or the table codepage to match, you can force optimization to work as it did in Visual FoxPro 8 and prior versions using the SET ENGINEBEHAVIOR Command with either 80 or 70 as a parameter."
Leo Schmidt
Yep, you are right. I alsready wrote a little code to utilize CPZERO to change all my tables to CP 1252.
Now things look brighter.
Unfortuinately I think I may be missing this month's meeting as well...
Alen.