ActiveX component can't create object.

[Liz]

When I click on tools>security>user-level security wizard I receive the
message in the subject above. I also receive it when trying to use linked
manager.

The references I've got enabled are:
Visual Basic for applications
microsoft access 11.0 object library
microsoft activex data objects 2.1 library
micorosft dao 3.6 object library
ole automation
microsoft ado ext. 2.8 for ddl and security

Can someone point me to where I can find the solution for this problem? I've
already got the latest jet engine.
Thanks
Liz

 

[Chris Mills]

It's a common problem, and I'm damned if I can remember all the answers.
(there seem to be several, I've struck some)

Have you done this?
http://search.support.microsoft.com/search/?adv=1
and search for "ActiveX component can't create object"

As an aside, you have too many references.
You NEVER need ole automation, even if you USE ole automation, so far as I
know.
It would be unusual, though possible, to use both ADO and DAO in the same app.

I'm not sure why you are using the Security Wizard. Some advice (including
mine) is to avoid so-called "wizards" and do it yourself, especially the
Security Wizard. How do you know what it does and stuffs up and therefore, how
do you know what security you have? (The SecFaq puts the wizard in as a step,
which many think is wrong)

The Security Wizard is a design-time problem. If your only issues are
design-time problems then you have no issues at all. When that message crops
up on a customer site, then I would be more likely to stand up and take notice
(and it has for me, though I'm no longer sure of all the possible causes)

Chris

 

[Chris Mills]

Thanks for the examples, Jamie (or Liz, whom was addressed).
That seems to be so.

I must retract NEVER and replace it with OFTEN, SOMETIMES, or MAYBE
(...OLE Automation reference not being necessary)

No-one has posted what it's needed for (AFAIK), and it's not for my apps.

More importantly, did LIZ find a result for the original problem?
Cheers
Chris

 

[Chris Mills]

And thankyou for enumerating some cases where the reference "OLE Automation"
is used!

I thought you were using Access. Now you say that's not the case!

 

[Chris Mills]

So much for "OLE Automation" (hey not your fault! )

I vaguely recall the Treeview Control is not recommended, but rather use
system ones similar to recommendation for FileDialog?

Is there no limit to Jamie's enumerations? <guffaw>

Chris ;-)
(somehow, I don't need "OLEAutomation" reference and I suspect many don't
also, though it's not really a "troublesome reference" for the getting rid of
or not)

(but I will Never Say Never Again, Jamie Bond)

And thankyou for enumerating some cases where the reference "OLE Automation"
[stdole] is used!

I thought you were using Access. Now you say that's not the case!

Here's an Access example: while writing a proposal for this thread:

http://groups.google.com/group/microsoft.public.access/msg/3bd882d028573fd2

I noticed this:

Option Compare Database

Private WithEvents m_Tree As MSComctlLib.TreeView

Private Sub m_Tree_MouseUp( _
ByVal Button As Integer, _
ByVal Shift As Integer, _
ByVal x As stdole.OLE_XPOS_PIXELS, _
ByVal y As stdole.OLE_YPOS_PIXELS)

Jamie

 

[Chris Mills]

In either case, you're quite right

I recently read (in a book, must have been a parable)
"What's the largest number?"
Some small girl said: "64!"
Teacher says: "what if you add 1 to it?"
Small girl says: "Well, I was pretty close!"

Cheers

 

[Chris Mills]

Can you assist Liz?
It was the point of this thread.
However pathetic, I did try. All your stuff was side-track.

Your entire posts merely indicate a pointscoring fetish over "never", which is
all good fun until we realise, Liz might well be still struggling with the
problem...

just a thought...
Chris

 

[Chris Mills]

Having reviewing the thread, I don't think it's unusual to use ADO and

DAO in the same project...

I think that is unusual. ADO was a "failed" replacement for DAO, or at least
for an Access-only installation. I can't enumerate the reasons to use both, so
it's for you to find some.

...or are you running for MVP again
this year <g>?

<guffaw>
One would need to value the prize, a Universal Subscription including the
latest Access!!! (I stopped at A2002)

How do you "run for MVP?" Seems to be your own perception coz I can't glean it
from anything I said.

What the hell did he mean? FTR I'm unsuitable. Whilst not apparently asking
many questions, I learn lots from the newsgroups too. I think you should
contribute more.

Chris

 

[Chris Mills]

Having reviewing the thread, I don't think it's unusual to use ADO and

DAO in the same project...

Jamie,
Can you give a reason for this view?

A quick perusal of newsgroups (which I haven't done recently, more perusal
over years), might show many posts containing ADO and DAO in the same
sentence.

Some of them say, if you use both references, how to make sure your code
differerentiates between them.
(some statements being otherwise identical in both, though with vastly
different results)

I believe, in many cases both references are there only because Access2000 or
higher inserts ADO reference as a default whether you use it or not, and the
operator may well just be using DAO. A successful conversion from A97 will
eliminate the ADO reference (though never guaranteed).

You can search for yourself, "DAO ADO" on www.microsoft.com. and here's one
result which states DAO is more suitable for pure Access:
http://support.microsoft.com/kb/225048/

I believe I have read more withering viewpoints of ADO, though probably not on
the Microsoft site!

Anyway, regardless of the merits of either, you seem to be claiming there is
reason to implement BOTH, in the same app. All I ask is, Why Exactly?

Chris

(I have never myself used ADO.The reviews I read were enough to put me off,
when DAO does all I imagined I ever needed. Even if I did like ADO, surely I
would convert... or not? Certainly, my apps are pure Access, and my readings
are that DAO remains the best for that?)

 

[Chris Mills]

one MVP once mentioned a free MSFT wristwatch <g>!

Well, if I'd known that, I would have happily supported ADO...

 

[Chris Mills]

Most interesting, thanks. It is true that my interest is Access/Jet, where DAO
vs ADO (I use a top-down order <g>) seems to document a preference for DAO.
Not legacy (though that's a good reason), but because I get the impression
that ADO did not live up to it's replacement expectations.

But my original reason (the subject heading!) was not the merits between them,
but that Access sticks in some default references which might not be used. If
they are used then they are of course. But Access can have problems with ANY
reference falling over (such as needing re-registering) and whether it's
actually used in the code or not. One thing to limit this "DLL Hell", is to
remove unnecessary references!

(that is, I have fixed the mentioned error by re-registering DAO, and ADO and
OLEAutomation were not witnesses to the problem)

I think...perhaps I could have fixed it by removing DAO...
Cheers
Chris