Multiple problems with access on this computer

[Heidi]

There is a program in access that we use here at work that has continual
problems but only on my computer. I just started here so I am just beginning
to research to find out what the problem is - I have no idea who created it
but I think it's been here awhile.

One of the issues is that when I try to run a report thru any of the forms,
it gives me an OnClick error, stating the object or class does not support
the set of events. I've tried to go into the back end of the database to see
if I could fix the problem but the design mode in both the forms and reports
are greyed out in every instance, as is the ability to create a new one from
scratch. I believe the problem is with the forms though because the either
give me all sorts of different errors from event procedure errors to
reference errors or they don't open at all. The reports however open up
beautifully from the backend.

My 2nd issue is that every time I am in the front end of the program and
then finsh whatever I'm doing and close it, it brings up the Microsoft Error
tracking window asking me to send a report of the error and then opens access
back up (unless I uncheck the box). Only thing is, there weren't any problems
to create an error....

Any clues on either of these at all? Would it simply be something corrupted
in my Access application since other people can use it and I can't?

Thanks for your help in advance,
Heidi

 

[david epsom dot com dot au]

You have a ".MDE" file, not a ".MDB", you can't view
the code or form design.

Forms and Code are normally in the Front End of a database,
not the Back End.

You have a "references" problem: there is a broken
reference to some other object, which is missing or
not installed or installed differently on that PC.

Because you have an MDE, it is difficult to check or
fix the references. Here is a VB Script to help you:

'......copy and paste from here
' Check Reference
const sFile = "c:\my documents\db1.mdb"

dim oAccess
dim oRef
set oAccess = wscript.getobject(sfile)

for each oref in oAccess.References
wscript.echo oref.name & " Is broken? " & oref.isbroken
next

wScript.Quit( 0 )
'.......to here

copy the script and past it into notepad or wordpad. Change sFile (const
sfile) to point to your problem database. Save the file as text and change
the file extension to .vbs

Double click on the file to run it (if VB Script has not been disabled on
the problem PC),

Read the messages to see if any of your references are shown as broken, then
return here for further information...


(david)

 

[Heidi]

David,

I copied/pasted/ran the script and I got an error message:

Script: (my local drive folder where the script is located)
Line: 1
Char: 1
Error: Invalid Character
Code: 800A0408
Source: Microsoft VBScript compilation error

I tried it with pointing the file w/an mde extension rather than the mdb
since there is not a file w/taht name and extension and got the same error.

Here is the code after it converted it to the vbscript:

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0
Verdana;}{\f1\fswiss\fcharset0 Arial;}}
{\*\generator Msftedit 5.41.15.1507;}\viewkind4\uc1\pard\f0\fs15 Check
Reference\par
const sFile = "c:\\local centertrack\\centertrack.mde"\par
dim oAccess\par
dim oRef\par
set oAccess = wscript.getobject(sfile)\par
for each oref in oAccess.References\par
wscript.echo oref.name & " Is broken? " & oref.isbroken\par
next\par
wScript.Quit( 0 )\fs20\par
\f1\par
}


Any clues? Thanks!!

 

[david epsom dot com dot au]

No :~) that is not a text file...

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\
Verdana;}{\f1\fswiss\fcharset0 Arial;}}
{\*\generator Msftedit 5.41.15.1507;}\viewkind4\uc1\pard\f0\fs15
Reference\par

That is an RTF file, probably generated by something called MSFTedit :~)

The script file has to start at "dim oAccess" -- and it
must be "dim oAccess", not "dim oAccess\par"

You must save the file as "text" or "MS DOS Text" or "Plain Text" or
something like that. Word or Wordpad or Textpad or most editors will
be able to do that.

(david)

 

[Heidi]

Ok now I got it! Sorry about that...

It went thru a whole list of things it checked and after each one w/a
question of whether it was broken or not said False. So is it just not
finding it because it's an mde file and like you said, it's harder to locate
breaks or is that not the problem and it's something else?

Thanks a bunch!

 

[david epsom dot com dot au]

It could be database corruption - in which case copying
the file from another computer would fix the problem.
Otherwise, it is still likely to be a 'references'
problem, but more subtle.

The next thing to try would be re-registering each
of the references that were listed.

Replace the wscript.echo line in the script with this:

wscript.echo oref.FullPath
c:\windows\system32\regsvr32 oref.fullpath


(david)

 

[Heidi]

Well let me ask this and double check then before I try to re-register the
references and it doesn't change... The main file and the back end file
w/just the tables in it is located on the network so I went and copied that
one rather than using the one located on my hard drive and it still doesn't
work. Yet other people do not seem to have any problems using it. Would it
then be feasible to question whether there is a problem with my computer
itself? Is it possible that somewhere in Office or in the registry there is a
piece missing? If not, I'll work on the referneces next, I just don't wnat to
make futile attempts with it at this point...

Thanks again

 

[david epsom dot com dot au]

itself? Is it possible that somewhere in Office or in the registry there

a piece missing?

Yes, and the most important obvious pieces are the pieces
listed as references. This really is the place to start.

The script may fix the problem.

Or it may be that when you run the script, one of the
references will come up with a bad path, or fail to register
- in which case we can fix the problem.

If it still doesn't work after that, the next step is to check
the file location of each of the references, and compare to
a working machine.

And eventually, you are going to be trying stuff like
un-installing Office, cleaning your hard drive, and then
re-installing. Or perhaps just wiping your hard disk and
starting over.

But we aren't up to that place yet. There are still other
things we can try to nail down which piece of Office or
the registry isn't correct.

(david)

 

[Heidi]

Ok, I ran the script change like you wrote earlier and got an error in the
compiler:

Line: 7, Char: 7, Error: Expected Statement

Which is the backslash in the path name....

const sFile = "c:\local centertrack\centertrack.mde"
dim oAccess
dim oRef
set oAccess = wscript.getobject(sfile)
for each oref in oAccess.References
wscript.echo oref.FullPath
c:\windows\system32\regsvr32 oref.Fullpath
next
wScript.Quit( 0 )

Did I copy something that I shouldn't have? Or is this what we're looking for?

Thanks

 

[Guest]

That was my fault: I tried to keep the change too simple.
Note that the location of regsvr32 may vary. It may be
in c:\windows\

'--------
const sFile = "c:\local centertrack\centertrack.mde"
dim oAccess, oRef
set oAccess = wscript.getobject(sfile)
for each oref in oAccess.References
wscript.echo oref.FullPath
if not oref.builtin then
createobject("wscript.shell").run _
"c:\windows\system32\regsvr32.exe " _
& """" & oref.Fullpath & """",1,true
end if
next
wScript.Quit( 0 )
'--------

 

[Heidi]

Ok, it went thru a bunch of files with their paths and most it just listed
w/an "ok" button but there were a couple that it listed and included
"DllRegisterServer [path] succeeded", and a few that said "[path] was loaded
but the DllRegisterServer entry point was not found.... [path] does not
appear to be a .DLL or .OCX file".... I'm assuming that those are the ones
that are not correctly referencing?

 

[Guest]

I excluded the Built In references because they don't have
a DllRegisterServer entry point. Those are the VBA and
Access references. If we don't succeed with the other references,
we will have to revisit those.

The ones which succeeded are almost certainly ok.

The ones that failed are the ones to look at next. They may
be OK, or they may not.

You should try the application (just in case registering the few
references fixed the problem), then can you post the whole
list for us here?

(david)

Ok, it went thru a bunch of files with their paths and most it just listed
w/an "ok" button but there were a couple that it listed and included
"DllRegisterServer [path] succeeded", and a few that said "[path] was loaded
but the DllRegisterServer entry point was not found.... [path] does not
appear to be a .DLL or .OCX file".... I'm assuming that those are the ones
that are not correctly referencing?

That was my fault: I tried to keep the change too simple.
Note that the location of regsvr32 may vary. It may be
in c:\windows\

'--------
const sFile = "c:\local centertrack\centertrack.mde"
dim oAccess, oRef
set oAccess = wscript.getobject(sfile)
for each oref in oAccess.References
wscript.echo oref.FullPath
if not oref.builtin then
createobject("wscript.shell").run _
"c:\windows\system32\regsvr32.exe " _
& """" & oref.Fullpath & """",1,true
end if
next
wScript.Quit( 0 )
'--------

 

[Heidi]

Ok - i'm assuming the ones that were simply listed w/out any comments such as
succeeded or not found, etc, are ok? I won't list them for time's sake so if
they are worth noting, let me know and I will...Also, for time's sake, i"m
just going to list the files themselves, if the path is necessary as well,
let me know....

(and no, the db is still not working correctly)

the following files were listed with this as the statement: ... "was loaded
but the DllRegisterServer entry point was not found" .... "does not appear to
be a .dll or .ocx file"

msado21.tlb
msoutl.olb
stdole2.tlb

I excluded the Built In references because they don't have
a DllRegisterServer entry point. Those are the VBA and
Access references. If we don't succeed with the other references,
we will have to revisit those.

The ones which succeeded are almost certainly ok.

The ones that failed are the ones to look at next. They may
be OK, or they may not.

You should try the application (just in case registering the few
references fixed the problem), then can you post the whole
list for us here?

(david)

Ok, it went thru a bunch of files with their paths and most it just listed
w/an "ok" button but there were a couple that it listed and included
"DllRegisterServer [path] succeeded", and a few that said "[path] was loaded
but the DllRegisterServer entry point was not found.... [path] does not
appear to be a .DLL or .OCX file".... I'm assuming that those are the ones
that are not correctly referencing?

That was my fault: I tried to keep the change too simple.
Note that the location of regsvr32 may vary. It may be
in c:\windows\

'--------
const sFile = "c:\local centertrack\centertrack.mde"
dim oAccess, oRef
set oAccess = wscript.getobject(sfile)
for each oref in oAccess.References
wscript.echo oref.FullPath
if not oref.builtin then
createobject("wscript.shell").run _
"c:\windows\system32\regsvr32.exe " _
& """" & oref.Fullpath & """",1,true
end if
next
wScript.Quit( 0 )
'--------

There is a program in access that we use here at work that
has continual
problems but only on my computer. I just started here so I am
just beginning
to research to find out what the problem is - I have no idea
who created it
but I think it's been here awhile.
One of the issues is that when I try to run a report thru any
of the forms,
it gives me an OnClick error, stating the object or class
does not support
the set of events. I've tried to go into the back end of the
database to see
if I could fix the problem but the design mode in both the
forms and reports
are greyed out in every instance, as is the ability to create
a new one from
scratch. I believe the problem is with the forms though
because the either
give me all sorts of different errors from event procedure
errors to
reference errors or they don't open at all. The reports
however open up
beautifully from the backend.
My 2nd issue is that every time I am in the front end of the
program and
then finsh whatever I'm doing and close it, it brings up the
Microsoft Error
tracking window asking me to send a report of the error and
then opens access
back up (unless I uncheck the box). Only thing is, there
weren't any problems
to create an error....
Any clues on either of these at all? Would it simply be
something corrupted
in my Access application since other people can use it and I
can't?
Thanks for your help in advance,
Heidi

 

[david epsom dot com dot au]

msado21.tlb

msoutl.olb
stdole2.tlb

These are header/index files, which is why
they don't have a DllRegisterServer entry point.

Out of all the things that might be different about
this PC, the most likely is that Outlook is installed
differently on this PC, causing a problem with the
MSOUTLook reference.

Are you using Outlook? Is it the same version on this PC? Does it work
correctly?

ADO 2.1 is 5 years old: I don't know how to get a clean copy of that.
However, you can try checking it using the MDAC checker:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8f0a8df6-4a21-4b43-bf53-14332ef092c9
If the checker turns up any problems, fix them.

OLE is part of windows: my guess would be that if there was
any problem with the OLE library, you would see more problems
than just running this one application.

(david)

Ok - i'm assuming the ones that were simply listed w/out any comments such
as
succeeded or not found, etc, are ok? I won't list them for time's sake so
if
they are worth noting, let me know and I will...Also, for time's sake, i"m
just going to list the files themselves, if the path is necessary as well,
let me know....

(and no, the db is still not working correctly)

the following files were listed with this as the statement: ... "was
loaded
but the DllRegisterServer entry point was not found" .... "does not appear
to
be a .dll or .ocx file"

msado21.tlb
msoutl.olb
stdole2.tlb

I excluded the Built In references because they don't have
a DllRegisterServer entry point. Those are the VBA and
Access references. If we don't succeed with the other references,
we will have to revisit those.

The ones which succeeded are almost certainly ok.

The ones that failed are the ones to look at next. They may
be OK, or they may not.

You should try the application (just in case registering the few
references fixed the problem), then can you post the whole
list for us here?

(david)

Ok, it went thru a bunch of files with their paths and most it just
listed
w/an "ok" button but there were a couple that it listed and included
"DllRegisterServer [path] succeeded", and a few that said "[path] was loaded
but the DllRegisterServer entry point was not found.... [path] does not
appear to be a .DLL or .OCX file".... I'm assuming that those are the
ones
that are not correctly referencing?



:

That was my fault: I tried to keep the change too simple.
Note that the location of regsvr32 may vary. It may be
in c:\windows\

'--------
const sFile = "c:\local centertrack\centertrack.mde"
dim oAccess, oRef
set oAccess = wscript.getobject(sfile)
for each oref in oAccess.References
wscript.echo oref.FullPath
if not oref.builtin then
createobject("wscript.shell").run _
"c:\windows\system32\regsvr32.exe " _
& """" & oref.Fullpath & """",1,true
end if
next
wScript.Quit( 0 )
'--------

There is a program in access that we use here at work that
has continual
problems but only on my computer. I just started here so I am
just beginning
to research to find out what the problem is - I have no idea
who created it
but I think it's been here awhile.
One of the issues is that when I try to run a report thru any
of the forms,
it gives me an OnClick error, stating the object or class
does not support
the set of events. I've tried to go into the back end of the
database to see
if I could fix the problem but the design mode in both the
forms and reports
are greyed out in every instance, as is the ability to create
a new one from
scratch. I believe the problem is with the forms though
because the either
give me all sorts of different errors from event procedure
errors to
reference errors or they don't open at all. The reports
however open up
beautifully from the backend.
My 2nd issue is that every time I am in the front end of the
program and
then finsh whatever I'm doing and close it, it brings up the
Microsoft Error
tracking window asking me to send a report of the error and
then opens access
back up (unless I uncheck the box). Only thing is, there
weren't any problems
to create an error....

Any clues on either of these at all? Would it simply be
something corrupted
in my Access application since other people can use it and I
can't?

Thanks for your help in advance,
Heidi

 

[Heidi]

Ok, I ran the checker and it lists files but it doesn't necessarily give
errors or fixes... When I ran it specifically against the current version of
the ado, it gave a longer list of files and had a mismatch field where some
are listed, the rest say "none", but it still doesn't have any other options
to fix it.... any guidance?

As far as outlook, I haven't had any problems with it yet - it's 2002 sp3
and i'm running windows xp sp2. But i haven't noticed any problems....

msado21.tlb
msoutl.olb
stdole2.tlb

These are header/index files, which is why
they don't have a DllRegisterServer entry point.

Out of all the things that might be different about
this PC, the most likely is that Outlook is installed
differently on this PC, causing a problem with the
MSOUTLook reference.

Are you using Outlook? Is it the same version on this PC? Does it work
correctly?

ADO 2.1 is 5 years old: I don't know how to get a clean copy of that.
However, you can try checking it using the MDAC checker:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8f0a8df6-4a21-4b43-bf53-14332ef092c9
If the checker turns up any problems, fix them.

OLE is part of windows: my guess would be that if there was
any problem with the OLE library, you would see more problems
than just running this one application.

(david)

Ok - i'm assuming the ones that were simply listed w/out any comments such
as
succeeded or not found, etc, are ok? I won't list them for time's sake so
if
they are worth noting, let me know and I will...Also, for time's sake, i"m
just going to list the files themselves, if the path is necessary as well,
let me know....

(and no, the db is still not working correctly)

the following files were listed with this as the statement: ... "was
loaded
but the DllRegisterServer entry point was not found" .... "does not appear
to
be a .dll or .ocx file"

msado21.tlb
msoutl.olb
stdole2.tlb

I excluded the Built In references because they don't have
a DllRegisterServer entry point. Those are the VBA and
Access references. If we don't succeed with the other references,
we will have to revisit those.

The ones which succeeded are almost certainly ok.

The ones that failed are the ones to look at next. They may
be OK, or they may not.

You should try the application (just in case registering the few
references fixed the problem), then can you post the whole
list for us here?

(david)


Ok, it went thru a bunch of files with their paths and most it just
listed
w/an "ok" button but there were a couple that it listed and included
"DllRegisterServer [path] succeeded", and a few that said "[path] was
loaded
but the DllRegisterServer entry point was not found.... [path] does not
appear to be a .DLL or .OCX file".... I'm assuming that those are the
ones
that are not correctly referencing?



:

That was my fault: I tried to keep the change too simple.
Note that the location of regsvr32 may vary. It may be
in c:\windows\

'--------
const sFile = "c:\local centertrack\centertrack.mde"
dim oAccess, oRef
set oAccess = wscript.getobject(sfile)
for each oref in oAccess.References
wscript.echo oref.FullPath
if not oref.builtin then
createobject("wscript.shell").run _
"c:\windows\system32\regsvr32.exe " _
& """" & oref.Fullpath & """",1,true
end if
next
wScript.Quit( 0 )
'--------

There is a program in access that we use here at work that
has continual
problems but only on my computer. I just started here so I am
just beginning
to research to find out what the problem is - I have no idea
who created it
but I think it's been here awhile.
One of the issues is that when I try to run a report thru any
of the forms,
it gives me an OnClick error, stating the object or class
does not support
the set of events. I've tried to go into the back end of the
database to see
if I could fix the problem but the design mode in both the
forms and reports
are greyed out in every instance, as is the ability to create
a new one from
scratch. I believe the problem is with the forms though
because the either
give me all sorts of different errors from event procedure
errors to
reference errors or they don't open at all. The reports
however open up
beautifully from the backend.
My 2nd issue is that every time I am in the front end of the
program and
then finsh whatever I'm doing and close it, it brings up the
Microsoft Error
tracking window asking me to send a report of the error and
then opens access
back up (unless I uncheck the box). Only thing is, there
weren't any problems
to create an error....

Any clues on either of these at all? Would it simply be
something corrupted
in my Access application since other people can use it and I
can't?

Thanks for your help in advance,
Heidi

 

[Guest]

the ado, it gave a longer list of files and had a mismatch field where
some

are listed, the rest say "none", but it still doesn't have any other

options

It is just a checker. If there are problems, you have to fix them yourself.

If you let it automatically detect the version, and it has mismatches, then
you have a problem which may be causing your Access problem, and
can probably be fixed by downloading and installing the current MDAC
version:
http://www.microsoft.com/downloads/...95-efc2-4f8e-a9e0-3a1afbd5922e&DisplayLang=en

If you checked the specific version 2.1 and the checker reported problems,
it is because you have a later version installed, which is probably not the
simple cause of the problem.

What version does the MDAC checker report if run on other PC's?

As far as outlook, I haven't had any problems with it yet - it's 2002 sp3
and i'm running windows xp sp2. But i haven't noticed any problems....

Well, you have noticed problems, that is why you are here :~).
The problem would be if your version is different from the version
installed on all the other PC's, or was installed in a different location.

What version of Windows and Office are installed on all the other PC's?

(david)

Ok, I ran the checker and it lists files but it doesn't necessarily give
errors or fixes... When I ran it specifically against the current version of
the ado, it gave a longer list of files and had a mismatch field where some
are listed, the rest say "none", but it still doesn't have any other options
to fix it.... any guidance?

As far as outlook, I haven't had any problems with it yet - it's 2002 sp3
and i'm running windows xp sp2. But i haven't noticed any problems....

msado21.tlb
msoutl.olb
stdole2.tlb

These are header/index files, which is why
they don't have a DllRegisterServer entry point.

Out of all the things that might be different about
this PC, the most likely is that Outlook is installed
differently on this PC, causing a problem with the
MSOUTLook reference.

Are you using Outlook? Is it the same version on this PC? Does it work
correctly?

ADO 2.1 is 5 years old: I don't know how to get a clean copy of that.
However, you can try checking it using the MDAC checker:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8f0a8df6-4a21-4b43-bf53-14332ef092c9
If the checker turns up any problems, fix them.

OLE is part of windows: my guess would be that if there was
any problem with the OLE library, you would see more problems
than just running this one application.

(david)

Ok - i'm assuming the ones that were simply listed w/out any comments such
as
succeeded or not found, etc, are ok? I won't list them for time's sake so
if
they are worth noting, let me know and I will...Also, for time's sake, i"m
just going to list the files themselves, if the path is necessary as well,
let me know....

(and no, the db is still not working correctly)

the following files were listed with this as the statement: ... "was
loaded
but the DllRegisterServer entry point was not found" .... "does not appear
to
be a .dll or .ocx file"

msado21.tlb
msoutl.olb
stdole2.tlb



:

I excluded the Built In references because they don't have
a DllRegisterServer entry point. Those are the VBA and
Access references. If we don't succeed with the other references,
we will have to revisit those.

The ones which succeeded are almost certainly ok.

The ones that failed are the ones to look at next. They may
be OK, or they may not.

You should try the application (just in case registering the few
references fixed the problem), then can you post the whole
list for us here?

(david)


Ok, it went thru a bunch of files with their paths and most it just
listed
w/an "ok" button but there were a couple that it listed and included
"DllRegisterServer [path] succeeded", and a few that said "[path] was
loaded
but the DllRegisterServer entry point was not found.... [path] does not
appear to be a .DLL or .OCX file".... I'm assuming that those are the
ones
that are not correctly referencing?



:

That was my fault: I tried to keep the change too simple.
Note that the location of regsvr32 may vary. It may be
in c:\windows\

'--------
const sFile = "c:\local centertrack\centertrack.mde"
dim oAccess, oRef
set oAccess = wscript.getobject(sfile)
for each oref in oAccess.References
wscript.echo oref.FullPath
if not oref.builtin then
createobject("wscript.shell").run _
"c:\windows\system32\regsvr32.exe " _
& """" & oref.Fullpath & """",1,true
end if
next
wScript.Quit( 0 )
'--------

There is a program in access that we use here at work that
has continual
problems but only on my computer. I just started here so I am
just beginning
to research to find out what the problem is - I have no idea
who created it
but I think it's been here awhile.
One of the issues is that when I try to run a report thru any
of the forms,
it gives me an OnClick error, stating the object or class
does not support
the set of events. I've tried to go into the back end of the
database to see
if I could fix the problem but the design mode in both the
forms and reports
are greyed out in every instance, as is the ability to create
a new one from
scratch. I believe the problem is with the forms though
because the either
give me all sorts of different errors from event procedure
errors to
reference errors or they don't open at all. The reports
however open up
beautifully from the backend.
My 2nd issue is that every time I am in the front end of the
program and
then finsh whatever I'm doing and close it, it brings up the
Microsoft Error
tracking window asking me to send a report of the error and
then opens access
back up (unless I uncheck the box). Only thing is, there
weren't any problems
to create an error....

Any clues on either of these at all? Would it simply be
something corrupted
in my Access application since other people can use it and I
can't?

Thanks for your help in advance,
Heidi

 

[Heidi]

Ok, when I just run it without specifically running for the 2.1, it just
lists a few files, names and then in the next field, the word "file". It does
however after I run it, it continually asks, "The following product releases
were matched: MDAC 2.8 SP1 on Windows XP SP2 would you like to re-run query
for a specific product release?" and it brings me back to the same screen
where I choose to run on the entire machine or just on the mdac 2.1. If i run
again, it loops back to taht same message and we're back to where we started.
So in short, no it doesn't list errors, but it doen'st really give a great
picture either....

the ado, it gave a longer list of files and had a mismatch field where some
are listed, the rest say "none", but it still doesn't have any other

options

It is just a checker. If there are problems, you have to fix them yourself.

If you let it automatically detect the version, and it has mismatches, then
you have a problem which may be causing your Access problem, and
can probably be fixed by downloading and installing the current MDAC
version:
http://www.microsoft.com/downloads/...95-efc2-4f8e-a9e0-3a1afbd5922e&DisplayLang=en

If you checked the specific version 2.1 and the checker reported problems,
it is because you have a later version installed, which is probably not the
simple cause of the problem.

What version does the MDAC checker report if run on other PC's?

As far as outlook, I haven't had any problems with it yet - it's 2002 sp3
and i'm running windows xp sp2. But i haven't noticed any problems....

Well, you have noticed problems, that is why you are here :~).
The problem would be if your version is different from the version
installed on all the other PC's, or was installed in a different location.

What version of Windows and Office are installed on all the other PC's?

(david)

Ok, I ran the checker and it lists files but it doesn't necessarily give
errors or fixes... When I ran it specifically against the current version of
the ado, it gave a longer list of files and had a mismatch field where some
are listed, the rest say "none", but it still doesn't have any other options
to fix it.... any guidance?

As far as outlook, I haven't had any problems with it yet - it's 2002 sp3
and i'm running windows xp sp2. But i haven't noticed any problems....

msado21.tlb
msoutl.olb
stdole2.tlb

These are header/index files, which is why
they don't have a DllRegisterServer entry point.

Out of all the things that might be different about
this PC, the most likely is that Outlook is installed
differently on this PC, causing a problem with the
MSOUTLook reference.

Are you using Outlook? Is it the same version on this PC? Does it work
correctly?

ADO 2.1 is 5 years old: I don't know how to get a clean copy of that.
However, you can try checking it using the MDAC checker:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8f0a8df6-4a21-4b43-bf53-14332ef092c9
If the checker turns up any problems, fix them.

OLE is part of windows: my guess would be that if there was
any problem with the OLE library, you would see more problems
than just running this one application.

(david)




Ok - i'm assuming the ones that were simply listed w/out any comments such
as
succeeded or not found, etc, are ok? I won't list them for time's sake so
if
they are worth noting, let me know and I will...Also, for time's sake, i"m
just going to list the files themselves, if the path is necessary as well,
let me know....

(and no, the db is still not working correctly)

the following files were listed with this as the statement: ... "was
loaded
but the DllRegisterServer entry point was not found" .... "does not appear
to
be a .dll or .ocx file"

msado21.tlb
msoutl.olb
stdole2.tlb



:

I excluded the Built In references because they don't have
a DllRegisterServer entry point. Those are the VBA and
Access references. If we don't succeed with the other references,
we will have to revisit those.

The ones which succeeded are almost certainly ok.

The ones that failed are the ones to look at next. They may
be OK, or they may not.

You should try the application (just in case registering the few
references fixed the problem), then can you post the whole
list for us here?

(david)


Ok, it went thru a bunch of files with their paths and most it just
listed
w/an "ok" button but there were a couple that it listed and included
"DllRegisterServer [path] succeeded", and a few that said "[path] was
loaded
but the DllRegisterServer entry point was not found.... [path] does not
appear to be a .DLL or .OCX file".... I'm assuming that those are the
ones
that are not correctly referencing?



:

That was my fault: I tried to keep the change too simple.
Note that the location of regsvr32 may vary. It may be
in c:\windows\

'--------
const sFile = "c:\local centertrack\centertrack.mde"
dim oAccess, oRef
set oAccess = wscript.getobject(sfile)
for each oref in oAccess.References
wscript.echo oref.FullPath
if not oref.builtin then
createobject("wscript.shell").run _
"c:\windows\system32\regsvr32.exe " _
& """" & oref.Fullpath & """",1,true
end if
next
wScript.Quit( 0 )
'--------

There is a program in access that we use here at work that
has continual
problems but only on my computer. I just started here so I am
just beginning
to research to find out what the problem is - I have no idea
who created it
but I think it's been here awhile.
One of the issues is that when I try to run a report thru any
of the forms,
it gives me an OnClick error, stating the object or class
does not support
the set of events. I've tried to go into the back end of the
database to see
if I could fix the problem but the design mode in both the
forms and reports
are greyed out in every instance, as is the ability to create
a new one from
scratch. I believe the problem is with the forms though
because the either
give me all sorts of different errors from event procedure
errors to
reference errors or they don't open at all. The reports
however open up
beautifully from the backend.
My 2nd issue is that every time I am in the front end of the
program and
then finsh whatever I'm doing and close it, it brings up the
Microsoft Error
tracking window asking me to send a report of the error and
then opens access
back up (unless I uncheck the box). Only thing is, there
weren't any problems
to create an error....

Any clues on either of these at all? Would it simply be
something corrupted
in my Access application since other people can use it and I
can't?

Thanks for your help in advance,
Heidi

 

[david epsom dot com dot au]

Ok, it thinks you have MDAC 2.8 SP1, and it doesn't find any problems.

To recap: you have an Access file which crashes on this PC, but
works correctly on other PC's. You would like to fix whatever is
broken or different on this PC so that the application runs
correctly.

What version does the MDAC checker report if run on other PC's?
What version of Windows and Office are installed on all the other PC's?
What version of Outlook is installed on all the other PC's?

Is a full version of Access installed on your PC?
If so, create a new database, go to the VB window,
(add a new module) and try to re-create all of the
references (Tools, References).


Ok, when I just
run it without specifically running for the 2.1, it just

lists a few files, names and then in the next field, the word "file". It
does
however after I run it, it continually asks, "The following product
releases
were matched: MDAC 2.8 SP1 on Windows XP SP2 would you like to re-run
query
for a specific product release?" and it brings me back to the same screen
where I choose to run on the entire machine or just on the mdac 2.1. If i
run
again, it loops back to taht same message and we're back to where we
started.
So in short, no it doesn't list errors, but it doen'st really give a great
picture either....



:


What version does the MDAC checker report if run on other PC's?


What version of Windows and Office are installed on all the other PC's?

(david)


msado21.tlb
msoutl.olb
stdole2.tlb

These are header/index files, which is why
they don't have a DllRegisterServer entry point.

Out of all the things that might be different about
this PC, the most likely is that Outlook is installed
differently on this PC, causing a problem with the
MSOUTLook reference.

Are you using Outlook? Is it the same version on this PC? Does it work
correctly?

ADO 2.1 is 5 years old: I don't know how to get a clean copy of that.
However, you can try checking it using the MDAC checker:

http://www.microsoft.com/downloads/details.aspx?FamilyID=8f0a8df6-4a21-4b43-bf53-14332ef092c9
If the checker turns up any problems, fix them.

OLE is part of windows: my guess would be that if there was
any problem with the OLE library, you would see more problems
than just running this one application.

(david)


There is a program in access that we use here at work that
has continual
problems but only on my computer. I just started here so I am
just beginning
to research to find out what the problem is - I have no idea
who created it
but I think it's been here awhile.
One of the issues is that when I try to run a report thru any
of the forms,
it gives me an OnClick error, stating the object or class
does not support
the set of events. I've tried to go into the back end of the
database to see
if I could fix the problem but the design mode in both the
forms and reports
are greyed out in every instance, as is the ability to create
a new one from
scratch. I believe the problem is with the forms though
because the either
give me all sorts of different errors from event procedure
errors to
reference errors or they don't open at all. The reports
however open up
beautifully from the backend.
My 2nd issue is that every time I am in the front end of the
program and
then finsh whatever I'm doing and close it, it brings up the
Microsoft Error
tracking window asking me to send a report of the error and
then opens access
back up (unless I uncheck the box). Only thing is, there
weren't any problems
to create an error....

 

[Heidi]

Ok - on our network most have laptops w/Win XP and at least Outlook 2003 if
not Office as well (I'm assuming since normally you buy the whole package), 1
or two have desktops with this as well, and a couple still have desktops
w/Win XP, Office/Outlook XP. Mine is the latter. I dont know whether or not
he MDAC will find the same things becasue I'm not the administrator and don't
have access to other people's computers especially since they are laptops. I
may be able to ask our tech to run it but again w/laptops I'm not sure it's
most feasible request...

I'm pretty sure it's the full version of Access - I'm in the middle of
creating another db (w/out modules however) and have not had any problems
yet. Of course, this is an MDB...

I tried to go into the references section but ran into a bit of a snag b/c
the orig file that i'm having problems with won't let me into the module
("global code") because it's an MDE, so I can't recreate it or check the
references from the other one.... Unless I'm just missing something and they
should be standard?

 

[Guest]

The first test, when we looked to see if anything "isBroken",
didn't tell us that anything was broken, and the application
works ok on other PC's, so now we are looking for something
subtle.

most have laptops w/Win XP and at least Outlook 2003 if
a couple still have desktops w/Win XP, Office/Outlook XP.

This could be the subtle thing we are looking for: Perhaps it
is an Office 2003 application, not an Office XP application,
or, your application has a reference to Outlook, and perhaps
it works on computers with Outlook 2003, but not with Outlook
XP.

First, let's test if it really is an MDE. Load the application,
press [ctl][G] to take you to the immediate window. Type
this in and press [return] (you may not be able to paste):

?codedb.Properties("mde")

If you get "T", then your application is an MDE. If not then
you will probably need to get a computer with Office 2003.

(david)