Access Program in 2003 will not run in 2007

J

johnrerwin

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 ass 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
 
F

Fred

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

a a r o n . k e m p f

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
 
T

Tony Toews [MVP]

johnrerwin said:
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.
Click to expand...

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
--
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/
 
H

hewang

Tony Toews said:
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
--
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/
Click to expand...
 
A

a a r o n . k e m p f

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

-Aaron
 
T

Tony Toews [MVP]

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

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
--
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/
 
A

aaron_kempf

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
 
R

Roger Carlson

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.

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

a a r o n . k e m p f

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

Roger Carlson

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.

--
--Roger Carlson
MS Access MVP
www.rogersaccesslibrary.com
message
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.
 
A

a a r o n . k e m p f

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
 
A

a a r o n . k e m p f

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
 
Top