Does it perform the same if you use enginebehavior 80?

When you say "optimized" I guess you are basing this on the response obtained and not on VFP's SYS(3054) return.

It does look like there's something odd going on.


>>You say the command is simplified.
>>Are the result times you define for the simplified command or for the original command?
>>
>>If for the original, we'll need to see all of the JOINs and you'll need to tell us if there are TAGs on the joined fields.
>>
>>If for the simplified version, my bet is that the second is so fast simply because the data is already cached and VFP is using the cache.
>
>Here is a SQL that I am using as is. I just changed the table names:
>
>

>SELECT Member.*,Item.AI FROM Member;
> INNER JOIN Status ON Member.NoStatus=Status.Numero;
> INNER JOIN Item ON Member.NoDBUsers=Item.Numero;
> WHERE Item.Numero=3042 AND Member.NoEntity=1 AND;
> (Status.Numero=2 OR Status.Numero=9 OR Status.Numero=3 OR Status.Numero=5 OR Status.Numero=16)
>

>
>But, here is the interesting part. If I add another set of fields after Item.AI, the result is fully optimized:
>
>

>SELECT Member.*,Item.AI,Status.* FROM Member;
> INNER JOIN Status ON Member.NoStatus=Status.Numero;
> INNER JOIN Item ON Member.NoDBUsers=Item.Numero;
> WHERE Item.Numero=3042 AND Member.NoEntity=1 AND;
> (Status.Numero=2 OR Status.Numero=9 OR Status.Numero=3 OR Status.Numero=5 OR Status.Numero=16)
>

>
>So, this shows that there is something buggy in the way the engine works. This could be affected on some data corruption, bad tags or something like that. But, it just doesn't make any sense that I will get an immediate result just because I add Status.* at the end of the field list.