Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / General 2 / April 2008

Tip: Looking for answers? Try searching our database.

Access Program in 2003 will not run in 2007

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
johnrerwin - 15 Apr 2008 16:18 GMT
I have written a program that I have used for years and it runs fine, but
when updating to 2007 it will not run.  An error message reads that file
DA0253 needs to be updated but I cannot find an update.

Is it possible to install 2003 on the same hard disk a.s 2007 and both run
independently of the other?  If this is so, I can do this if 2003 will not
overwrite 2007

Thank you
John Erwin
Charlottesville, Virginia
Fred - 15 Apr 2008 19:07 GMT
I run them both on one machine.  No problems seen yet other than it goes
through a lot of fanfare each time I switch between them.   This is on XP.  

Is this by any chance on Vista?  If so, I'd upgrade to XP.   Vista is
designed to prevent you from doing all of the normal things that you need to
do when you use a PC.    

> I have written a program that I have used for years and it runs fine, but
> when updating to 2007 it will not run.  An error message reads that file
[quoted text clipped - 7 lines]
> John Erwin
> Charlottesville, Virginia
a a r o n . k e m p f @ g m a i l . c o m - 15 Apr 2008 22:13 GMT
Fred;

I feel the same way about JET ;)

John R Erwin;

I would reccomend just learning Access 2007.

and finding the reference problem.

I believe that if you just uncheck the library called Access Database
Objects- I think that it is called something like that- then you
should be able to _SEE_ the places that refer to DAO..

I would go through there and look for something that refers to
Dim rst as DAO.Recordset.2.53
then you should just remove the .2.53 from the end.
-- I think that something like this might be the root of the problem.

I believe that you can also use this syntax with the CreateObject
procedure.. I'm not positive though ;)

Then you might want to re-check the DAO checkbox under Tools,
References-- if you must.  Personally; I prefer to use ADO because ADO
is everywhere and DAO is not.

Thanks & Good Luck

-Aaron

> I run them both on one machine.  No problems seen yet other than it goes
> through a lot of fanfare each time I switch between them.   This is on XP.  
[quoted text clipped - 16 lines]
>
> - Show quoted text -
Tony Toews [MVP] - 16 Apr 2008 03:16 GMT
>I have written a program that I have used for years and it runs fine, but
>when updating to 2007 it will not run.  An error message reads that file
>DA0253 needs to be updated but I cannot find an update.

Your problem has to do with references.  Ctrl+G will take you into the
Debug/Immediate window.  Then click on Tools on the menu bar and
References.

One of your references will be to a DAO 2.5/3.5 compatibility
something or other.  Remove that reference and compile the code.  

Now you may find some DAO code that won't work properly.  For example
rs.FieldName will have to be changed to rs!FieldName and similar.
There may be a few other wierdnesses that you will have to work
through.

Also what references do exist?

Sub ViewReferenceDetails()

Dim ref As Reference
   
   For Each ref In Access.References
       Debug.Print ref.Name & " - " & ref.Major & "." & ref.Minor & "
- " & ref.FullPath
   Next ref

End Sub

Tony
Signature

Tony Toews, Microsoft Access MVP
  Please respond only in the newsgroups so that others can
read the entire thread of messages.
  Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
  Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

hewang - 16 Apr 2008 07:54 GMT
"Tony Toews [MVP]" <ttoews@telusplanet.net>
??????:g5oa04pl2fk6ah3v654dnt8bs75aqlaj4i@4ax.com...

>>I have written a program that I have used for years and it runs fine, but
>>when updating to 2007 it will not run.  An error message reads that file
[quoted text clipped - 26 lines]
>
> Tony
a a r o n . k e m p f @ g m a i l . c o m - 16 Apr 2008 19:39 GMT
Yes.. of course; if you 'just used ADO' then you wouldn't ever have to
deal with the missing DAO libraries.

-Aaron

> >I have written a program that I have used for years and it runs fine, but
> >when updating to 2007 it will not run.  An error message reads that file
[quoted text clipped - 32 lines]
>    Microsoft Access Links, Hints, Tips & Accounting Systems athttp://www.granite.ab.ca/accsmstr.htm
>    Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
Tony Toews [MVP] - 16 Apr 2008 23:27 GMT
"a a r o n . k e m p f @ g m a i l . c o m" <aaron.kempf@gmail.com>
wrote:

>Yes.. of course; if you 'just used ADO' then you wouldn't ever have to
>deal with the missing DAO libraries.

This problem has nothing to do with ADO and likely comes from a
database that was converted from long before ADO was available in
Access.

Tony
Signature

Tony Toews, Microsoft Access MVP
  Please respond only in the newsgroups so that others can
read the entire thread of messages.
  Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
  Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

aaron_kempf@hotmail.com - 17 Apr 2008 00:35 GMT
Tony-

DAO is obsolete.
DAO is not included - by default - in Access 2000, 2002, 2003 or 2007.

Now _HOW_ is it that you're saying that it 'isnt DAOs fault'?

I don't think that you get the root of the problem
The root of the problem is that DAO is a _CRAP_ library.

Any library-- that makes you explicitly _CLOSE_ and _DEALLOCATE_
variables.. is a waste of time.
Any library-- that IS NOT INSTALLED BY DEFAULT - is a waste of time.

Anything that uses DAO should be moved to ADO. Sorry-- those are the
_FACTS_.
Anything that uses DAO should be moved to ADO. Sorry-- those are the
_FACTS_.

And your little 'oh but I can't loop through the tables in ADO'-- that
kinda bullshit mis-information that you give?
I just won't stand for it any longer.

ADO can do everything that DAO can.. and it's _FASTER_ and its
_STABLE_ and it's omnipresent.

DAO is none of those 3.

It's just not worth it, Tony.   I'm right-- DAO is the root of the
problem.  If you're tired of dealing with DAO _CRAP_ then move to ADO.

Case Closed!

-Aaron

> "a a r o n . k e m p f @ g m a i l . c o m" <aaron.ke...@gmail.com>
> wrote:
[quoted text clipped - 13 lines]
>    Microsoft Access Links, Hints, Tips & Accounting Systems athttp://www.granite.ab.ca/accsmstr.htm
>    Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
Roger Carlson - 17 Apr 2008 08:23 GMT
This is, of course, false on it's face.

1) Create a NEW Access 2003 database (mdb), create a New Module, go to
Tools>References and the "Microsoft DAO 3.6 Object Model" will be
selected -- By Default -- and will, in fact, be above the the ADO object
model reference, which means it has precident.

2) Create a New Access 2007 database (again, mdb), create a New Module, go
to Tools>References and ONLY DAO will be selected -- by default.  ADO
doesn't even appear.

3) Create a New Access 2007 database (this time accdb), create a New Module,
go to Tools>References.  You will see a reference to "Microsoft Office
Access Database Engine Object Library".  Ha, you say.  Not DAO.  Well, that
would be wrong.  If you create a subroutine and type:
   dim db as DAO.Database
intellisense will fill in both the "DAO" and "Database", AND it will
compile, proving that DAO is installed.  The reference is just the new name
for DAO in the ACCDB format.  DAO continues to be extended into future
versions.

BTW, in your new Access 2007 database (either mdb or accdb) if you type:
   Dim conn As ADODB.Connection
intellisense WILL NOT fill in "ADODB" or "Connection" and it will throw a
compile error.  Proving that ADO is not installed by default in Access 2007.

Signature

--Roger Carlson
MS Access MVP
www.rogersaccesslibrary.com

Tony-

DAO is obsolete.
DAO is not included - by default - in Access 2000, 2002, 2003 or 2007.

Now _HOW_ is it that you're saying that it 'isnt DAOs fault'?

I don't think that you get the root of the problem
The root of the problem is that DAO is a _CRAP_ library.

Any library-- that makes you explicitly _CLOSE_ and _DEALLOCATE_
variables.. is a waste of time.
Any library-- that IS NOT INSTALLED BY DEFAULT - is a waste of time.

Anything that uses DAO should be moved to ADO. Sorry-- those are the
_FACTS_.
Anything that uses DAO should be moved to ADO. Sorry-- those are the
_FACTS_.

And your little 'oh but I can't loop through the tables in ADO'-- that
kinda bullshit mis-information that you give?
I just won't stand for it any longer.

ADO can do everything that DAO can.. and it's _FASTER_ and its
_STABLE_ and it's omnipresent.

DAO is none of those 3.

It's just not worth it, Tony.   I'm right-- DAO is the root of the
problem.  If you're tired of dealing with DAO _CRAP_ then move to ADO.

Case Closed!

-Aaron

On Apr 16, 3:27 pm, "Tony Toews [MVP]" <tto...@telusplanet.net> wrote:
> "a a r o n . k e m p f @ g m a i l . c o m" <aaron.ke...@gmail.com>
> wrote:
[quoted text clipped - 14 lines]
> athttp://www.granite.ab.ca/accsmstr.htm
> Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
a a r o n . k e m p f @ g m a i l . c o m - 17 Apr 2008 08:36 GMT
This is, of course, false on it's face.

1) Create a NEW Access 2003 database (ADP), create a New Module, go
to
Tools>References and the "Microsoft ActiveX Data Objects 2.8 Object
Model" will be
selected -- By Default --  DAO doesn't even appear.

1.3) Create a NEW Access 2002 database (ADP), create a New Module, go
to
Tools>References and the "Microsoft ActiveX Data Objects 2.8 Object
Model" will be
selected -- By Default --  DAO doesn't even appear.

1.6) Create a NEW Access 2000 database (ADP), create a New Module, go
to
Tools>References and the "Microsoft ActiveX Data Objects 2.8 Object
Model" will be
selected -- By Default --  DAO doesn't even appear.

2) Create a New Access 2000 database (again, mdb), create a New
Module, go
to Tools>References and ONLY ADO will be selected -- by default.  DAO
doesn't even appear.

2.5) Create a New Access 2002 database (again, mdb), create a New
Module, go
to Tools>References and ONLY ADO will be selected -- by default.  DAO
doesn't even appear.

3) Create a New Access 2007 database (this time ADP), create a New
Module,
go to Tools>References.  You will see a reference to "Microsoft
ActiveX Database Objects 2.8 or 6.0 or something.. depending on which
version of Windows you've got".  Ha, you say.  Not ADO.  Well, that
would be wrong.

If you create a subroutine and type:
   dim db as ADO.Connection
intellisense will fill in both the "ADO" and "Connection", AND it
will
compile, proving that ADO is installed.  The reference is just the new
name
for ADO in the ACCDB format.  ADO continues to be extended into
future
versions.

BTW, in your new Access 2007 database (ADP) if you type:
   Dim conn As DAO.Connection
intellisense WILL NOT fill in "DAO" or "Connection" and it will throw
a
compile error.  Proving that DAO is not installed by default in Access
2007.

--
--Aaron Kempf
MCITP: Database Administrator
AKA - the only one around here with enough _BRAINPOWER_ to _EARN_
their certifications.

On Apr 17, 12:23 am, "Roger Carlson"
<rogerdotjdotcarlsonatgmaildot...@nospam.com> wrote:
> This is, of course, false on it's face.
>
[quoted text clipped - 86 lines]
>
> - Show quoted text -
Roger Carlson - 17 Apr 2008 15:27 GMT
Your arguments grow more specious every day.  Citing Access 2000 and 2002 is
pretty weak since those versions are 5 to 8 years old.  Why not cite Access
2.0?  It's just as pertinent.

Oh, and which type of database is created -- BY DEFAULT -- in Access 2003
(since you're so concerned about defaults)?  MDB, not ADP.  Which type of
database is created by default in Access 2007?  ACCDB, not ADP.  Neither of
which create a default library reference to ADO, but do create one to DAO.

Signature

--Roger Carlson
MS Access MVP
www.rogersaccesslibrary.com

This is, of course, false on it's face.

1) Create a NEW Access 2003 database (ADP), create a New Module, go
to
Tools>References and the "Microsoft ActiveX Data Objects 2.8 Object
Model" will be
selected -- By Default --  DAO doesn't even appear.

1.3) Create a NEW Access 2002 database (ADP), create a New Module, go
to
Tools>References and the "Microsoft ActiveX Data Objects 2.8 Object
Model" will be
selected -- By Default --  DAO doesn't even appear.

1.6) Create a NEW Access 2000 database (ADP), create a New Module, go
to
Tools>References and the "Microsoft ActiveX Data Objects 2.8 Object
Model" will be
selected -- By Default --  DAO doesn't even appear.

2) Create a New Access 2000 database (again, mdb), create a New
Module, go
to Tools>References and ONLY ADO will be selected -- by default.  DAO
doesn't even appear.

2.5) Create a New Access 2002 database (again, mdb), create a New
Module, go
to Tools>References and ONLY ADO will be selected -- by default.  DAO
doesn't even appear.

3) Create a New Access 2007 database (this time ADP), create a New
Module,
go to Tools>References.  You will see a reference to "Microsoft
ActiveX Database Objects 2.8 or 6.0 or something.. depending on which
version of Windows you've got".  Ha, you say.  Not ADO.  Well, that
would be wrong.

If you create a subroutine and type:
   dim db as ADO.Connection
intellisense will fill in both the "ADO" and "Connection", AND it
will
compile, proving that ADO is installed.  The reference is just the new
name
for ADO in the ACCDB format.  ADO continues to be extended into
future
versions.

BTW, in your new Access 2007 database (ADP) if you type:
   Dim conn As DAO.Connection
intellisense WILL NOT fill in "DAO" or "Connection" and it will throw
a
compile error.  Proving that DAO is not installed by default in Access
2007.

--
--Aaron Kempf
MCITP: Database Administrator
AKA - the only one around here with enough _BRAINPOWER_ to _EARN_
their certifications.

On Apr 17, 12:23 am, "Roger Carlson"
<rogerdotjdotcarlsonatgmaildot...@nospam.com> wrote:
> This is, of course, false on it's face.
>
[quoted text clipped - 89 lines]
>
> - Show quoted text -
a a r o n . k e m p f @ g m a i l . c o m - 18 Apr 2008 00:38 GMT
re:
Oh, and which type of database is created -- BY DEFAULT -- in Access
2003
(since you're so concerned about defaults)?  MDB, not ADP.  Which type
of
database is created by default in Access 2007?  ACCDB, not ADP.
Neither of
which create a default library reference to ADO, but do create one to
DAO.

Are you asking 'which option is the most popular'?

Is that what you're asking?

Neither one is the default.  One is obsolete; and one is not.

Again-- it is not called DAO... dude.. Did you not catch that?? It has
nothing to do with DAO.  It's not called DAO.  It's not DAO.

Thanks

-Aaron

On Apr 17, 7:27 am, "Roger Carlson"
<rogerdotjdotcarlsonatgmaildot...@nospam.com> wrote:
> Your arguments grow more specious every day.  Citing Access 2000 and 2002 is
> pretty weak since those versions are 5 to 8 years old.  Why not cite Access
[quoted text clipped - 166 lines]
>
> - Show quoted text -
a a r o n . k e m p f @ g m a i l . c o m - 18 Apr 2008 00:43 GMT
and we'll just wait and see what the non-linear redmond beast decides
to do on this next release.

According to _MY_ calculations-- WinFS is still coming; which makes
MDB and ACCDB even more suspect

-Aaron

On Apr 17, 7:27 am, "Roger Carlson"
<rogerdotjdotcarlsonatgmaildot...@nospam.com> wrote:
> Your arguments grow more specious every day.  Citing Access 2000 and 2002 is
> pretty weak since those versions are 5 to 8 years old.  Why not cite Access
[quoted text clipped - 166 lines]
>
> - Show quoted text -
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.