Hey, Guy...

<< But what about when the end user wants to write their own reports with their version of Crystal? It seems they would be obligated to use ODBC, right? Do you encounter this problem? Any ideas? >>

I haven't come across this problem because none of our end-users have a copy of Crystal. I have a sort of 'poor-man's' custom-reporting module in the works, where I allow someone (through VFP) to determine what pieces of data they want to display, and then I map it to a basic Crystal 'template' (nothing more than an RPT with 10 pre-defined generic columns...column1, column2, etc.) For every column I write out, I also write out a 'field type definition' column to tell Crystal about any special formatting for the column itself.

If your end-users have a copy of CRW, they'll need to map their RPT file to a pre-defined database. If they select a database that's in a native VFP 3/5 format, then I guess the answer would be yes, they'll need to go through ODBC. However, I strongly discourage this, especially when the pre-defined VFP database they're using is a large table and they only want a subset of the data.

IMHO, CRW does not yield acceptable performance when operating/querying against a large database file. That's why I use the capabilities of Rushmore to whittle down the data to only that which the report will need.

Finally, FWIW, I've been pretty disappointed with the direction Seagate is taking (and isn't taking) with this product. In talking to many of their support staff (and their supervisors), they don't seem to have a good understanding of what many developers 'hope' to get out of their reporting product. There's some great functionality but an almost equal amount of 'quirkiness' that has me researching some alternatives, like 'ActiveReports' by Data Dynamics (even though I'll have to use VB to get it to work.)

Hope this helps,
Kevin