Hi, This post is a little lengthy, but I'm hoping that someone out there will take pity on a former VC++ developer who has been forced into VB development for the past two years and who would like to move back to VC++. I have a project that is in need of a re-write. Now would be the perfect time to switch from VB COM development to VC++ COM development. I have a team of people who are in favor of the switch, but their experience with C++ is not extensive. In an attempt to make the switch I have sought out these past two weeks all information I could find on developing ATL components for COM+. My application is a web site, so the components will be accessed from ASP pages and the COM components will access a SQL Server 2000 database. I have encountered many hurdles. The first of which is that most tutorials assume that the reader wants to know EVERYTHING about ATL development. I can't afford for my people to get lost in the myriad of details. My components do not do much. They receive requests from ASP pages, access the database, massage data going in or going out and then pass back results to the ASP pages. Not rocket science. So, I do not need (initially anyway) to approach issues like aggregation or containment (except as they apply to object pooling). Second, it is very hard to locate information on directly needs to be done to ATL components to allow them to take best advantage of COM+. I know that there ARE such issues because I stumbled across an MSDN article that mentioned several issues such as how I must remove the NON_AGGREGATABLE #define from an object created from the MTS Object wizard option. Finally, I approached data access this weekend and was startled to understand that OLEDB is the preferred access method over ADO. That's all well and good, and I see hoe the wizards made using OLEDB a snap. However, I have yet to see an example that shows me how to use OLEDB to execute a stored procedure (I wrap my database in stored procedures and require that all access go through them). Also, in VB I had a COM object that represented each table in the database, but each of these COM objects accessed a single 'accessor' object for its database access. The OLEDB model (at least the ATL wizard anyway) sets up a model in which each of my 'table' COM objects would access the database directly. Is this a standard with OLEDB/ATL? Even if I use OLEDB and create OLEDB consumers, I currently pass ADO recordsets around and eventually I pass them to the ASP p