>Hi craig,
>
>>- No tables hanging around on disk that I need to clean up.
>
>Can be handled in classes, but ok it does seem to be a more clean method.

Yes, unless the application terminates abnormally.

>
>>- Easier to move the application to SQL Server
>
>I don't quite understand. Why is it easier ? You mean that the CR report can bypass VFP to get its data ? If VFP is still somewhere in the report process I don't see the advantage.

If I move the data from VFP to SQL Server, I just change the connection string. No "Convert Database Driver" needed. (BTW, this feature was removed in CR9)

>
>>- Crystal can handle the entire reporting process including data selection
>
>You mean via SQL statements ? If only filtering, you can use the filter in CR.

Yup, via SQL statements

>
>>- I use ADO throughout the application... makes business objects easier to use
>
>Seems a rather subjective statement. I never use ADO and don't see where I should use ADO other than in Heterogenous n-tier environments where one of the tiers depend on ADO.

All my new work is nTier.

>
>>- MS recommends it
>
>Well, to me that is more and more reason to be suspicious ;-). Seriously, it does not seem a legimate reason to me.

I didn't say it was a good reason. *g*


>
>>- There is a bug with Crystal's xBase driver that causes memo fields in the report footer to not be printed under certain conditions. I reported this bug to Crystal Decisions and they have confirmed it.
>
>Hmmm.. I never noticed this. However I'll keep this in mind.
>

It depends on how you structure your data. In this case, I have two report DBFs, Header and Detail. Header.DBF has all the report and page header/footer information. If Detail.DBF has 213 or more records, the memos in Header.DBF are not printed in the report footer. The report prints correctly if I use ODBC or ADO to connect to the data.