I'm there with you, Craig--truly! "Should be" is the operative word here. Not so with Fox2x (non-DBC) databases, 9 times out of 10. Test it and prepare to be blown away! (Heck, I'd even test it with DBC's.) I was surprised, too--my company was doing a Crystal Enterprise roll-out and had to deal with some embarassingly slow speeds accessing legacy flat tables (Fox2x). Crystal Tech Support suggested we use ODBC, and a 17-minute run became a 2-second run. The speed increased so much that I had to test the validity of the report for my own peace of mind, AFTER we had already run those tests! The speed increase had nothing to do with Enterprise and everything to do with Reports (we tested that to be sure).

The same company (a large insurance company) then requested me to go to their Miami office (which drives the reporting and data maintenance for their Denver & Boston offices) for a week just to change all of their DBF-specific Crystal Reports to ODBC.

This is tested and true--chat with Tech Support about it.

JR

>Native access should be faster than either OLE DB or ODBC. OLE DB should be faster than ODBC.
>
>
>>I've got a client who has some large databases. I created a program that writes out a temporary file and then changes the table(s) of the report and spits out a Crystal Report. It works very nice, but it's slow. I can't seem to make ODBC VFP directories work with temporary files, but it looks like OLE DB will (I tried changing the table on a small report and it worked fine). I know that ODBC is much faster than native. Does anyone have experience with the speed of OLE DB as it relates to native? Is it worth going down that road?
>>
>>Joy