ActiveX component can't create object.

[Guest]

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

 

[onedaywhen]

You NEVER need ole automation, even if you USE ole automation, so far as I
know.

Following your advice, I removed the reference and I now get a compile
error on the line:

Public Property Get NewEnum() As IUnknown

BTW I use this in all my collection classes so I can enumerate their
members with For Each..Next.

Jamie.

--

 

[onedaywhen]

Following your advice, I removed the reference and I now get a compile
error on the line:

Public Property Get NewEnum() As IUnknown

Not to mention LoadPicture...

Jamie.

--

 

[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

 

[onedaywhen]

Thanks for the examples, Jamie (or Liz, whom was addressed).
I must retract NEVER and replace it with OFTEN, SOMETIMES, or MAYBE

I'm not the OP nor go by the name of Liz (I'll nip that one in the
bud).

Thank you for retracting your misstatement without me having to
elaborate on my VB6 project that uses StdPicture objects or my
Usercontrol that exposes an IFontDisp property or ...

Jamie.

--

 

[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!

 

[onedaywhen]

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!

True I haven't yet. But never say NEVER... <g>

Jamie.

--

 

[onedaywhen]

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]

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

 

[onedaywhen]

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

SELECT 2147483647 + 1

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

 

[onedaywhen]

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

I was responding to your 'As an aside' point, not the OP.

Having reviewing the thread, I don't think it's unusual to use ADO and
DAO in the same project...

I'm here to learn through reading and discussion. Call me selfish if
you like but don't try to deny that an of act of altruism doesn't leave
you with a warm fuzzy feeling inside...or are you running for MVP again
this year <g>?

Jamie.

--

 

[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?)

 

[onedaywhen]

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.

I stopped at A2002

If your clock stopped in 2002 then for you the official line is, "(DAO)
was the primary data access method. That has now changed. Although DAO
is still supported, the new way to access data is with ADO." I always
suspected DAO advocates were stuck in a time warp <vbg>.

For those of who are thinking of the future being Access 2007, DAO is
back in favour. However, to be frank, if you think ADO was a failed
experiment, you've got you've also got your head stuck in the sand.
Even in its Office 2007 incarnation, DAO still hasn't caught up with
ADO in terms of functionality i.e. properties, methods and events; why,
it still hasn't even got support for all the Jet 4.0 functionality!
Think about it: ADO was built on the success of DAO and learned from
its failings.

In a nutshell, there are things that you can do with ADO that you can't
do with DAO (similarly, there are things that DAO can do that ADO
can't; the vast majority can be achieved using either).

There are far too many things to 'enumerate' but let's briefly consider
the recordset. Things I can achieve with an ADO that I cannot with a
DAO recordset (and that I regularly use) include: disconnected
recordsets; persisting recordsets on disk (including XML format) which
can subsequently be reopened and used to update the source, using the
SHAPE syntax to create hierarchical recordsets; fetch records
asynchronously, using events such as _FetchProgress to be able to give
user feedback via a progress bar; paging using the PageSize,
AbsolutePage.

Generally, I find ADO a better coding experience: not having to
navigate the last record to be able to get an accurate record count;
easy to debug (e.g. the GetRows method can specify a subset of fields,
the GetString method, etc); flatter hierarchy allows a recordset to be
created without first explicitly creating a connection object, etc.

And this is just recordsets, off the top of my head and things I
actively use.

Actually, that last one reminds me why I am averse to DAO i.e. its
appalling teardown code which gave VBA a bad reputation is
unforgivable...

I can't deny, however, that the smart approach is to use both DAO and
ADO selectively, to take advantage of their relative merits. You may
not agree but then someone who can't see any merit in ADO may not be
the best judge.

One would need to value the prize, a Universal Subscription including the
latest Access!!!

It's better than that, I think: one MVP once mentioned a free MSFT

I think you should
contribute more.

I'm a 'quality, not quantity' person, myself. I probably put in at
least one hour per day on posting replies, though.

Jamie.

--

 

[Chris Mills]

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

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

 

[onedaywhen]

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/

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?

A couple of points about that article. Migrating an *existing* DAO/Jet
project to ADO/Jet is probably not going to be easy to justify and I
think the article reflects that well. Thus, a possible answer to your
question is revealed: do not reengineer existing DAO code but use ADO
going forward to be able to leverage new functionality.

As I think you concur, the contemporaneous articles pertaining to *new*
projects recommend ADO. So this article is a view of ADO from a DAO
perspective: I don't think there are any articles about migrating from
ADO/Jet to DAO/Jet, so we don't get the view of DAO from an ADO
perspective, perhaps because it wouldn't bee too complementary e.g. "If
you are using hierarchical recordset then this will have to cease; if
you relying on connecting/fetching asynchronously then you're out of
luck, ..."

But why linger on the past? Show me the article titled, 'Issues
Migrating from ADO/Jet to ACEDAO/Access 2007 engine.

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

I have experience of both DAO and ADO: I've worked on two major DAO/Jet
projects (one of which I spend several months converting to ADO/SQL
Server <g>). People aren't very complimentary about ADO in the Access
newsgroups, seemingly for subjective reasons of which I'm not entirely
sure (hurt feelings about something that happened a while ago...?) I
try to balance things out objectively when I can ;-)

Jamie.

--

 

[onedaywhen]

People aren't very complimentary about ADO in the Access
newsgroups, seemingly for subjective reasons of which I'm not entirely
sure (hurt feelings about something that happened a while ago...?) I
try to balance things out objectively when I can ;-)

Chris,
Much as I enjoy the ADO vs DAO (I'm using strict alpha order <g>)
debate, I think the best way of viewing things is that it's a lifestyle
choice. I think using ADO/Access is as valid as using DAO/Access and
view being derogatory about someone's choice either way a little
abhorrent (I don't think *you* were being derogatory but, as you know,
it does happen quite often around here, I'm afraid). Not wanting to
draw analogies but I'm also open minded someone being 'bi' (ADO+DAO) as
an equally valid lifestyle choice.

So how about we avoid the pejorative term 'unusual' and agree that
ADO+DAO is a valid if uncommon combination?

Cheers,
Jamie.

--