I assure you, even with Enterprise not in the equation, it can be faster. I'd really test and interview Tech Support before putting the finishing touches on that book of yours! I know it's hard to believe, and if I didn't see it with my own eyes, I'd be dubious too. But at least call Tech and talk to them about it. They suggested it and it did work (and as I said below, not necessarily with Enterprise in the equation).

FYI, the files I delt with are very wide--many fields--because they're flat. However, I have exprienced the same phenomenon with other clients and their situations (we at CLARC have certified Crystal Reports, Crystal Enterprise, and MCSD's on staff--we're very deep into this--and know what we're talking about as far as this specific issue goes).

JR

>I have tested it, and direct access is faster. Crystal Enterprise is a different animal from Crystal Reports, with an entirely different object model and components. The data access DLLs there may be different.
>
>
>>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
>>