Hi!

It could be related to differences in the default settigns in the environment, such as SET EXACT and SET ANSI, if you have any character comparison in the WHERE and HAVING.


>Tell me it isn't so. We have a complex query incorporating 4 INNER JOINS, 3 LEFT JOINS, a grouping and having clause, with a WHERE in there somewhere. It has been debugged in VFP 6 and returns the correct information. Against a particular dataset, it returns 5 records when running from the application in development mode. When the same app compiled in VFP 7 is run against the same data set, it returns 0 records. The query was segregated into a standalone program focused on the same dataset. When the segregated .prg was run in VFP 7, it returned 0 records. Run the same .prg in VFP 6 (recompiled), it returns 2 records. Even after restarting the machine (on the theory that somehow VFP 7 cached the query that VFP 6 ran thereafter), the .prg returns 2 records. When the application is then run in development mode against the same dataset, it returns two records. After restarting the machine, running VFP 6 in the application mode, we get back to 5 records returned. Run the .prg in VFP 6, get
>5 records. Run the .prg or the application in VFP 7, get 0 records. Go back and run the .prg in VFP 6, only 2 records returned again for as long as the machine's session is up.
>
>This is quite perplexing and at this point, we are suspending all VFP 7 implementation (where complex queries are involved) till we can find out where this is coming from.
>
>For the record, we are running off of the most current release and have installed all patches available on the MS site.
>
>Question is, anyone else hear of this behavior? Is there some intelligence in VFP 7 that somehow remaps the relations and orders of joins in the DBC for future queries whether done in 6 or 7. Some insight would be appreciated.
>
>Bill