Multiple problems with access on this computer

[Guest]

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)

 

[Guest]

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)

 

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

 

[Guest]

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 )
'--------

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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....

 

[Guest]

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)

 

[Guest]

Ok, I guess both good news and bad - I got the "T". So good that my outlook
isn't a problem, bad that we're still on the search.... What should I try
next?

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)

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?

 

[david epsom dot com dot au]

"T" means that it really is an MDE, so the fact that
you can't get into the forms and reports is not down
to some other problem. Next let's see what version it
thinks it is:

Open the application, type [ctrl][g], and into the
immediate window type

?codedb.version

and

?application.CodeProject.FileFormat

and

?syscmd(acsyscmdaccessver)

The first gives you the database file format, the
second gives you the format of the codeproject inside
that file, and the third (just for reference) give you
the version of Access you are using.

You won't be able to copy and paste those into the
window: the unbelievably irritating VBA environment
makes you type the stuff in.

(david)

PS: I'm glad you saw the last message: it never made
it back to my computer. Some kind of strange news
server anomaly.

Ok, I guess both good news and bad - I got the "T". So good that my
outlook
isn't a problem, bad that we're still on the search.... What should I try
next?

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)

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?