>Be careful of #1 if you ever plan on moving to SQL. This one bit us in several tender body parts, causing much blood, sweat, and tears (but without the cool horn section)
>

Yeah, I should have mentioned that. But then, I didn't say it was a GOOD idea ;-)

A bit off topic, but I've gone the "bare metal" route for most of my report writing. Although all of my reports are contained in their own classes, I tend to forgo the usual data access layer and do a SQL Select directly against the tables to build the reports. I even have a "standard" comment that I've put into these - basically a big disclaimer - that says: "This chunk of code will break if you move to SQL Server. Expect to rewrite these calls as stored procedures." Kind of a cop-out, but I have yet to find a way (that I like) of encapsulating this so that it's easy to use/write, retargetable, and fast. Using a new view for each select might work, but in those cases I'd really love to be able to use a different naming convention for them to physically separate them from my other views. That is, I don't want to prefix them with lv_ or rv_. Maybe rpt_. I've been to busy (read, lazy) to fix this, so I've just ignored the problem.

There, I've said it...I'm so ashamed < sniff > ;-)