>Nadya -
>
>Sorry about any confusion. I actually stripped out the comments, because they didn't add to the clarity.
>
>The data is structured like this:
>
>A provider (V_PROV) can have many releases (R_RELEAS), and many products (V_PROD)
>A product can have many registrations (P_PRODR)
>Registrations are on channels (V_CHAN)
>R_PRODR contains all the registrations for this release
>
>We're trying to get the following, in English [With field translations in brackets]:
>

"All of the movie [v_prod.prodclass='MOV'] registrations on VC channels
>[v_chan.vcchan=.t.] for the provider of the release which are either in this
>release [from R_PRODR] or are for a guarantee Product [v_prod.guarantee] or
>are for an Estimated provider [v_prov.est]."

>
>We pass this function the releasid (the PK of R_RELEAS), as tnReleasid.
>
>RELATIONS:
>V_PROV-->R_RELEAS (via prov_id)
>V_PROV-->V_PROD (via prov_id)
>V_PROD-->P_PRODR (via prod_id)
>P_PRODR-->V_CHAN (via chan_id)
>
>R_PRODR has 2 fields: releasid & prodrid.
>
>My problem is that I think that the three statements should get the same results. We ran the three statements against 90 different releases, and got the same results for 89 of them. For one release, we get three different tally's for the three different queries. This causes the provider to get underpaid by over $200,000 (which is an undesirable result!)
>
>We tried the having clause because it worked last month. Or so we thought. This month it turned up different results. We've re-indexed all the data, and are still perplexed.
>
>Thanks in advance for any information, and for even looking into this mess.
>
>I guess I could ZIP up the data and put it on our website, if it's necessary. It's not too big.
>
>- George
One more suggestion from "SWAG". Try to put explicitely v_chan = .t., etc. It should be unnecessary, but sometimes for strange reason makes a difference.