"spt_" prefix works for SQL pass-throughs, but we haven't tried anything other than the lv/rv for dbc views. I'd be interested to know what adventures in coding an unexpected view prefix would bring.

Don't be ashamed, Paul, you should see some of our disclaimers. Hee-hee, I'd hate to be a maintenance programmer here. Hey, wait a minute...

>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 > ;-)