Hi John

I often set deleted off when checking my queries. You will likely see more optimization levels at full. That's provided you have NO index on deleted(). That's probably a good thing. That doesn't mean it's not being optimized. Full optimization means it is as optimized as possible given the current environment.

>Sergey,
>
>The results are probably telling me that the joins are optimized and I just do not understand the results.
>
>The total results:
>
>Rushmore optimization level for table inmates: none
>Rushmore optimization level for table cells: none
>Rushmore optimization level for table classifications: none
>Rushmore optimization level for table bill_codes: none
>Joining table inmates and table cells using index tag id
>Joining intermediate result and table classifications using index tag id
>Joining intermediate result and table bill_codes using index tag id
>
>So I guess that means the joins are optimized because it says it is using an index but is confuses me because it also says "optimization level for table cells: none", etc. The VFP does not provide much info on how to read the results.
>
>Question: The VFP help says that you should not create indexes when there are only a few values. I do NOT have an index on Inmates.cStatus. It only contains values of 'OPEN' and 'CLOSED'. There are a lot more 'CLOSED' accounts than 'OPEN' ones and as time goes by more and more 'CLOSED' accounts are created while the number of 'OPEN' accounts remains about the same. 95% of the processing users do are to 'OPEN' accounts. Would it be a good idea to add an index on Inmates.cStatus? I should also say that this view is the most used view in the application. This view is used for the form that opens automatically when the application starts up. It takes several seconds to open the form. I am going to look at code in the refresh of this form as I suspect I may be able to make some improvements there as well.
>
>Question: All of the tables in my app have only 1 index. I use surrogate keys (guids) in all tables. Each table has a primary key on a field named cID which is the guid. All relationships are on these surrogate keys. I never access tables directly. I always use views to access the tables. According to VFP help I should have an index on each foreign key in each table. For example: I have a table named Inmates where cID is the primary key. I have a table named Purchases where cID is it's primary key. The field Purchases.cInmates_Id is the foreign key that relates Purchases to Inmates. Should I have a candidate key on Purchases.cInmates_Id? If I do this to all 100 or so tables that will be a major change to my app. I am a bit hesitatant to do such a major modification but the app is getting slower and some users are starting to access the app over a WAN which makes it very slow. I am within a few months of switching to VFP 9 and SQL Server. I thought it would be a good idea to optimize
>BEFORE the switch. Does that make sense?
>
>Thanks,
>John