MS Access Forum / General 2 / April 2008
Access Program in 2003 will not run in 2007
|
|
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 -
|
|
|