> Dear ATL-folk,
>    I've spent a few months learning about COM/COM+, and followed some
pretty
> good example code from Alan Gordon's "COM and COM+ Programming Primer"
> (recommended) to create a COM component that interacts with a database.
The
> examples all finish with registering the component in Component Services,
> utilizing lots of extra neat features which seemed important to the
author.
> However, after creating a version of the component for our server (with
> object construction, user permissions and what-not), I've decided instead
to
> make a light-weight version for the client that will ship with our
product,
> and have DB connection information passed in as a parameter.
>    Although most components I use in my scripts are obviously not
registered
> via Component Services, I still do not understand what differences in the
> programming allow for a COM dll to just be registered via "regsvr32
> foo_com.dll" before being called, and what necessitates the usage of
> Component Services.  I would like to change the project to not rely on
> Component Services.  I removed IObjectConstruct calls from the project,
> changed the parameters of my functions so the DB connection info can be
> passed in, then removed all traces of the past version of the component
from
> the registry, and regsvr32'd my new version.  Then I tried
> Server.CreateObject in an ASP page, and could access the simple methods,
but
> every call to a database access function would return a "class doesn't
> support automation" error.  If I create an empty COM+ application for it
in
> Component Services, and drop the .dll into it, the database access
functions
> work fine.  Could somebody explain at least generally what's going on?

> Thanks for any help,
> Dave Marble
> "Life is tough.  Life is tougher if you're stupid." -John Wayne

> Many times it's a marketing decision. As one market becomes saturated, the
> leader creates new and exciting technologies, and the market follows. Over
> enginerring is not always the best first solution. COM+ was designed to
> solve some concrete problems, and is a great tool. But just because a tool
> is great for one thing does not mean that its great for everthing.

> If the benifits & nessessity of using COM+ and how COM+ will solve your
> specific problems are not obvious (especially considering the effort you
> have already spent trying to discover a tangible benifit), then you may be
> better off sticking with a simpler method that meets the requirements.
Later
> on, you may start to see ways that you can use COM+ to enhance and improve
> your solution.

> Conan

> > Dear ATL-folk,
> >    I've spent a few months learning about COM/COM+, and followed some
> pretty
> > good example code from Alan Gordon's "COM and COM+ Programming Primer"
> > (recommended) to create a COM component that interacts with a database.
> The
> > examples all finish with registering the component in Component
Services,
> > utilizing lots of extra neat features which seemed important to the
> author.
> > However, after creating a version of the component for our server (with
> > object construction, user permissions and what-not), I've decided
instead
> to
> > make a light-weight version for the client that will ship with our
> product,
> > and have DB connection information passed in as a parameter.
> >    Although most components I use in my scripts are obviously not
> registered
> > via Component Services, I still do not understand what differences in
the
> > programming allow for a COM dll to just be registered via "regsvr32
> > foo_com.dll" before being called, and what necessitates the usage of
> > Component Services.  I would like to change the project to not rely on
> > Component Services.  I removed IObjectConstruct calls from the project,
> > changed the parameters of my functions so the DB connection info can be
> > passed in, then removed all traces of the past version of the component
> from
> > the registry, and regsvr32'd my new version.  Then I tried
> > Server.CreateObject in an ASP page, and could access the simple methods,
> but
> > every call to a database access function would return a "class doesn't
> > support automation" error.  If I create an empty COM+ application for it
> in
> > Component Services, and drop the .dll into it, the database access
> functions
> > work fine.  Could somebody explain at least generally what's going on?

> > Thanks for any help,
> > Dave Marble
> > "Life is tough.  Life is tougher if you're stupid." -John Wayne

> Dear ATL-folk,
>    I've spent a few months learning about COM/COM+, and followed some
pretty
> good example code from Alan Gordon's "COM and COM+ Programming Primer"
> (recommended) to create a COM component that interacts with a database.
The
> examples all finish with registering the component in Component Services,
> utilizing lots of extra neat features which seemed important to the
author.
> However, after creating a version of the component for our server (with
> object construction, user permissions and what-not), I've decided instead
to
> make a light-weight version for the client that will ship with our
product,
> and have DB connection information passed in as a parameter.
>    Although most components I use in my scripts are obviously not
registered
> via Component Services, I still do not understand what differences in the
> programming allow for a COM dll to just be registered via "regsvr32
> foo_com.dll" before being called, and what necessitates the usage of
> Component Services.  I would like to change the project to not rely on
> Component Services.  I removed IObjectConstruct calls from the project,
> changed the parameters of my functions so the DB connection info can be
> passed in, then removed all traces of the past version of the component
from
> the registry, and regsvr32'd my new version.  Then I tried
> Server.CreateObject in an ASP page, and could access the simple methods,
but
> every call to a database access function would return a "class doesn't
> support automation" error.  If I create an empty COM+ application for it
in
> Component Services, and drop the .dll into it, the database access
functions
> work fine.  Could somebody explain at least generally what's going on?

> Thanks for any help,
> Dave Marble
> "Life is tough.  Life is tougher if you're stupid." -John Wayne

> Works now.

> OK, tell me if I'm wrong on this: in my original code, I used
> CoGetObjectContext() -- which I believe for some reason is only available
if
> your component is configured.  Is that correct?  I commented out the
portion
> of the code which utilizes context state, and now the component works fine
> without configuring it as a COM+ app.  That'll do me for now... but I'd
like
> to understand why that is.

> -Dave

> > Dear ATL-folk,
> >    I've spent a few months learning about COM/COM+, and followed some
> pretty
> > good example code from Alan Gordon's "COM and COM+ Programming Primer"
> > (recommended) to create a COM component that interacts with a database.
> The
> > examples all finish with registering the component in Component
Services,
> > utilizing lots of extra neat features which seemed important to the
> author.
> > However, after creating a version of the component for our server (with
> > object construction, user permissions and what-not), I've decided
instead
> to
> > make a light-weight version for the client that will ship with our
> product,
> > and have DB connection information passed in as a parameter.
> >    Although most components I use in my scripts are obviously not
> registered
> > via Component Services, I still do not understand what differences in
the
> > programming allow for a COM dll to just be registered via "regsvr32
> > foo_com.dll" before being called, and what necessitates the usage of
> > Component Services.  I would like to change the project to not rely on
> > Component Services.  I removed IObjectConstruct calls from the project,
> > changed the parameters of my functions so the DB connection info can be
> > passed in, then removed all traces of the past version of the component
> from
> > the registry, and regsvr32'd my new version.  Then I tried
> > Server.CreateObject in an ASP page, and could access the simple methods,
> but
> > every call to a database access function would return a "class doesn't
> > support automation" error.  If I create an empty COM+ application for it
> in
> > Component Services, and drop the .dll into it, the database access
> functions
> > work fine.  Could somebody explain at least generally what's going on?

> > Thanks for any help,
> > Dave Marble
> > "Life is tough.  Life is tougher if you're stupid." -John Wayne

> Good to hear you got past the block.

> Im not an expert in the MTS / COM+ area, but I'll take a shot at it. MTS
> manages all the threading and stores a context for each thread. This
allows
> an MTS component developer to write the componet as a single threaded
> component. When activated, the component calls CoGetObjectContext to
obtain
> the correct context from MTS. An mts application would consist of a
> collection of small, single threaded components, each component performs a
> single task.

> There are sample components in the sdk MTSOnly/tutorial/componets
directory,
> some are for database access.

> Heres a couple links on CoGetObjectContext (from a google search).

> &nav=/msj/0999/newnav.htm

> http://archive.devx.com/free/mgznarch/vcdj/1999/julmag99/acom2.asp

> This one mentions about configuration issues:

> ocs/jbrennan.doc+CoGetObjectContext&hl=en&ie=UTF-8

> Conan

> > Works now.

> > OK, tell me if I'm wrong on this: in my original code, I used
> > CoGetObjectContext() -- which I believe for some reason is only
available
> if
> > your component is configured.  Is that correct?  I commented out the
> portion
> > of the code which utilizes context state, and now the component works
fine
> > without configuring it as a COM+ app.  That'll do me for now... but I'd
> like
> > to understand why that is.

> > -Dave

> > > Dear ATL-folk,
> > >    I've spent a few months learning about COM/COM+, and followed some
> > pretty
> > > good example code from Alan Gordon's "COM and COM+ Programming Primer"
> > > (recommended) to create a COM component that interacts with a
database.
> > The
> > > examples all finish with registering the component in Component
> Services,
> > > utilizing lots of extra neat features which seemed important to the
> > author.
> > > However, after creating a version of the component for our server
(with
> > > object construction, user permissions and what-not), I've decided
> instead
> > to
> > > make a light-weight version for the client that will ship with our
> > product,
> > > and have DB connection information passed in as a parameter.
> > >    Although most components I use in my scripts are obviously not
> > registered
> > > via Component Services, I still do not understand what differences in
> the
> > > programming allow for a COM dll to just be registered via "regsvr32
> > > foo_com.dll" before being called, and what necessitates the usage of
> > > Component Services.  I would like to change the project to not rely on
> > > Component Services.  I removed IObjectConstruct calls from the
project,
> > > changed the parameters of my functions so the DB connection info can
be
> > > passed in, then removed all traces of the past version of the
component
> > from
> > > the registry, and regsvr32'd my new version.  Then I tried
> > > Server.CreateObject in an ASP page, and could access the simple
methods,
> > but
> > > every call to a database access function would return a "class doesn't
> > > support automation" error.  If I create an empty COM+ application for
it
> > in
> > > Component Services, and drop the .dll into it, the database access
> > functions
> > > work fine.  Could somebody explain at least generally what's going on?

> > > Thanks for any help,
> > > Dave Marble
> > > "Life is tough.  Life is tougher if you're stupid." -John Wayne