>I worked for years with Crystal Reports and finally went back to FoxPro reporting for its simple productivity. I think Crystal's recent objects is a good direction for them as they always seemed so confused.
>
>Over the years I have gone back to loops and cursors after wasting too much time with sql and Crystal, but it was mainly because I switched from Visual Basic where I didn't have much choice to Visual FoxPro.
>
>Good Luck,
>
>>>Thanks for the responses so far...I guess I should have boiled my basic question down to this:
>>>
>>>If someone walked up to you and said that Crystal Repoorts can do _any_ report on its own (with no preprocessing by Fox and no changing of the data model), and, in fact, can do things that Fox cannot, would you say they are:
>>>
>>>a) Absolutely correct
>>>b) They might think they are right but they must be doing something under the hood other than Crystal
>>>c) they are just completely high.
>>>
>>>As for the following:
>>>
>>>>You didn't provide a complete description of your "end-date rules",
>>>>but I have a feeling that your problem can be solved with SQL.
>>>>It might involve a table of some sort that somehow contains your
>>>>rules. It might also involve joining your tables in such a way
>>>>as to produce a cursor where different events become different
>>>>fields in one record, rather than different records.
>>>
>>>It's not that I need to use different rules on the fly so that I need a dynamic list of them, and it's not a matter of denormalization either. It is a matter of needing to do a full scan of the data to see what the story is. We have rules like:
>>>
>>>"If a 'Y' line is followed by an 'R' line (anywhere in the order of lines, not just directly followed) with no 'A' or 'B' line in between, then the 'R' line is NOT considered a close. In that case the close will be the next 'A','B',or 'C' line after the 'R' (unless of course an 'X' is encountered which means the whole thing is aborted and shouldn't even be included in the report)."
>>>
>>>We may have a TREAT with two lines or a TREAT with 30 lines. The lines tell the whole story of a patients admission to the hospital, our approvals/denials of service, the patient's discharge, and the patient appeals (if any). Add in the ability to have aborts and technical denials, and I am hard pressed to see how any fixed set of SQL statements can come up with an accurate portayal of the lines and return to me a close date? I am well aware what nested SELECTs can help accomplish, but they don't seem to have a place here. Yes, a UDF() would work, but as was stated, that's not exactly SQL, and a UDF() that walks a database table isn't even possible in Crystal Reports, is it?
>>>
>>>Thanks again for the discussion!
>>>
>>>JoeK
>>
>>I get the feeling that you are really asking two different questions: 1) whether SQL is generally better than an xBase procedure for pre-processing and 2) whether Crystal Reports can do much that a native Fox report can't do. I haven't used Crystal Reports but I think that the two questions are really separate. It seems as if you will need to do some pre-processing one way or the other, no matter what reporting tool you use.
>>
>>I prefer SQL solutions partly because some of my worst programming nightmares have been thickets of IF...THENs which end up being just as hard as SQL to get right, at least for me.

Well, Codd himself proved that SQL CANNOT accomplish recursive queries. The type of query you have described appears to be a permutation of recursion, in that to determine if a record may be included, it must reference records in the same table in a sequential way.

I tend to agree with Date who likes to refer to Structured Query Language as Askew Wall. Meaning, imho, that the boundaries of SQL tend to become the boundaries of relational databases in people's minds. Relational databases can truly accomplish much more than SQL can describe. This is why VFP is such a great tool. It makes these accomplishments possible and easy.

my 2 cents,
Cheryl