--- Jeff <[EMAIL PROTECTED]> wrote: > is there a "rule of thumb" that will tell us whether we should use com+ for > our db transactions or not? We are converting a system from com/vb > to .net. I am trying to figure out whether we should just keep our > transaction layer in ado.net, the sproc level, or use com+ through > system.enterpiseservices. It is an interal intranet app, we are not > concerned with multi db (just sql 2k) platforms, or anything like that.
The main uses of COM+ are to gain distributed transactions, and to 'force' you to develop a layered model, with a clear transaction layer. In pre-dotnet days there was also a case for debugging, deployment, and error handling; which were relatively poorly supported by ASP. But these IMHO have disappeared with .Net. > Our biggest concern is supporting concurrent connections to db of about > 200+. COM+ adds some overhead, although not massive. Scalability is achieved through good database and data access design, and that's the case either with or without COM+. Peter __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
