upgrading from Access 97 to Access 2000 (1 Viewer)

ghudson

Registered User
Joined
Jun 8, 2002
Messages
6,199
I was just informed that some (not all) of my users are upgrading from Office 97 to Office 2000. What kind of problems can I expect with my Access 97 databases when the users computers go from Access 97 to Access 2000? The users will not be allowed to have Access 2000 and Access 97 installed on their PC's.

My main concerns are my secured Access 97 applications that are used and installed as runtimes. Most of the applications are heavily coded in VBA, secured and spilt with the user's front end on their PC which is linked to the back end on the server. Some are not split yet are shared by multiple users.

We have users who are using runtime versions of my secured Access 97 programs. What will happen when the users opens the secured Access 97 runtime db when their computer only has Access 2000?

All of our runtime applications are secured and use a custom short like this...
"C:\Program Files\Microsoft Office\Office\msaccess.exe" /runtime /wrkgrp "X:\Databases\Sample\Workgroup.mdw" "X:\Data\Bases\Testing\DB.mdb" /user Test User

As you might notice, the shortcut is pointing to the MSAccess.exe program which will be soon be the 2000 version of Access to be opened in as a secured runtime db.

I was under the impression that a secured Access runtime installation would work on any PC, no matter what (if any) version of Access is installed. Is that true! Will the secured Access 97 runtime installation work "as is" on any PC that has Office (Access) 2000 installed?

Might I add that I will only have Access 97 and the Office 97 Developers Edition on my computer.

Thanks in advance for your help and suggestions!
 

WayneRyan

AWF VIP
Joined
Nov 19, 2002
Messages
7,091
ghudson,

We recently migrated an A97 database to A2000.

It is a financial tracking application with hundreds of forms,
queries, reports and a LOT of VBA code. It is also coupled
with Microsoft Project.

The app is launched in a manner very similar to yours and
used the same .mdw file.

There were absolutely no problems whatsoever.

The only thing is getting used to how differently things "look"
when working in a design/maintenance mode.

I've heard before that DAO/ADO causes a lot of problems and
that performance is significantly less. I haven't seen this.

It'll be interesting to see what the others say ...

Wayne
 

ghudson

Registered User
Joined
Jun 8, 2002
Messages
6,199
That sounds encouraging. My main concern is that all my Access 97 databases will need to stay in their current version (Access 97) and be used as a secured runtime application on computers that only have Access 2000.

Will the Access 97 db open and run "as-is" a secured runtime Access 97 db on computers with only have Access 2000?

When I install the runtime applications setup files, will the setup installation overwrite the users Access 2000 msaccess.exe file with the Access 97 runtime's msaccess.exe file? If not, where will the installation process it put it? The secured Access 97 runtime db will need to use the Access 97 msaccess.exe file since that is what the shortcut will point to.

C:\Program Files\Microsoft Office\Office\msaccess.exe" /runtime /wrkgrp "X:\Databases\Sample\Workgroup.mdw" "X:\Data\Bases\Testing\DB.mdb" /user Test User

Thanks!
 

WayneRyan

AWF VIP
Joined
Nov 19, 2002
Messages
7,091
ghudson,

Now we're getting somewhere.

From what I've seen whenever an A2000 sees an A97
database it asks the user where to "convert it to 2000 or
open it as read only?" Read only would not seem to work and
converting it would lead to synch problems among other things.
We ensured that once we converted the A97 was no longer
available. I really don't think that A97 will open an A2000
database.


The 2000 installation will overwrite 97's files. There are
knowledge base articles on how to have a "dual" installation
but we had no desire to go down that road.

Like I said, it will be interesting to see what the others have
to say.

Wayne
 

rpadams

Registered User
Joined
Jun 17, 2001
Messages
111
Don't dismiss running both

If you really need to keep some of the Access97, don't dismiss the idea of keeping both systems. I do it and it has caused no problems. Just install 97 first and then install 2K in a NEW directory. This prevents the override. Since your operation has the path in the shortcut, it will automatically go to the right version.

I tried the route of having users NOT convert the 97 when they use 2K, but it is the default setting and it's easy to click away without thinking. Sure enough it didn't take long until I was loading copy after copy of the uncorrupted 97 back into the system. Your best bet is to convert everything to 2K but that may not be a good option depending on your application.
 

Pat Hartman

Super Moderator
Staff member
Joined
Feb 19, 2002
Messages
28,533
ghudson, there is no such thing as a runtime version of your Access database. Just open Access and open your app from there to prove it to yourself. The closest you can get is an .mde file which is a partially compiled db with all the source code removed. In an .mde, the forms/reports/modules cannot be opened in design mode.

The /runtime switch used in your shortcut, is simply telling the retail version of msaccess.exe to act like the runtime version of msaccess.exe. The runtime version of msaccess.exe can run an existing database but does not provide any GUI environment that can be used to modify table objects. If you remove the /runtime switch from your shortcut, your db will be totally accessable unless you have implemented Access security.

By using the developer's edition of Access, you can create an installation package that includes your (unmodified) .mdb or .mde and any supporting files along with (optionally) a copy of the msaccess.exe runtime version. If you go this route, you can usually have the runtime version of msaccess.exe for the appropriate version coexist with a different version of the full retail access product.
 

dfenton

AWF VIP
Joined
May 22, 2007
Messages
469
I'm at the point where I'm forgetting the problems, but here are the three that have given me the worst problems:

1. form/subform unload events don't necessarily fire in the same order. I had a nasty bug in one app where in A97, the subform unloaded before it's parent, but in A2003, the form was gone by the time the subform's Unload event fired. This caused terrible problems because I need to know certain things about Me.Parent of the subform, but at that point the parent form was gone. I ended up having to code around it via a different method and it ate up a huge amount of time.

2. references to fields in the underlying recordsources of forms are not as reliable in A2000 and later as in A97, particularly when between form/subform and vice versa. I particularly encountered it in A2000 with references from the subform to a field in the recordsource of the parent form (notice a pattern here?). The solution is to make a hidden control bound to the field you need to reference. The bottom line is that you just assume the Fields collection no longer exists, and use only the Controls collection (i.e., for any field you need to refer to in code, create a control for it).

3. references to values from controls on forms in saved QueryDefs don't resolve the same when the controls are Null. For instance, if you use a reference to a control to run an Append query (using Forms!MyForm!MyControl in the SELECT statement), if any of the controls are Null, the non-Null controls can be appended as Null. The solution is to declare your form references as parameters, or, better yet, use dynamic SQL and resolve the control references in code so you don't have to depend on the behavior of the Access expression service.

You will note that all three of these problems involve disconnects in the resolution of values in controls on forms. I believe that with the addition of the capability to use ADO recordsets on forms and reports, something fundamental was broken in the underlying architecture of Access forms and controls. There are workarounds for all of these, but it means looking at your app very carefully.

And the problems are not immediately obvious, as everything compiles and everything runs -- it's just that the results are not necessarily the same in A2000 and later as they were in A97.

That said, now that I do all my programming in A2003, I don't have too many problems. I would never do #3 any longer, #2 is a pretty easy workaround, and #1 happens very seldom in my apps (i.e., I don't have very many unload events in subforms that are poking around in the parent form).

But there are no doubt other problems that I've forgotten or that I've never encountered.

In short, I don't think it's such smooth sailing as others have suggested.
 

gemma-the-husky

Super Moderator
Staff member
Joined
Sep 12, 2006
Messages
13,873
i would definitely keep A97 as well as A2000. all access versions co-exist quite happily. I would also keep the backend as A97 if you can - A97 needs less resources, and works quicker than later versions, anyway.

more importantly, if your stuff is mission critical, you need to test it in A2000, and ought to give yourself the ability to keep these dbs's in A97 if necessary.

Personally, I wouldnt touch something thats working OK. FWIW, for most things A97 does a perfect jib, and its quicker and less resource hungry that later versions.

Access 97 help (.hlp) files are far easier to use than later (.chm) help files. I can never find anything in A2003


why office 2000/A2000 - its old anyway, and one to avoid I think

one problem is that access default was to use DAO in A97, then i think it changed to ADO in 2000, and back again to DAO afterwards. So you are likely to get issues in A2000
 

dfenton

AWF VIP
Joined
May 22, 2007
Messages
469
one problem is that access default was to use DAO in A97, then i think it changed to ADO in 2000, and back again to DAO afterwards. So you are likely to get issues in A2000
This is not an issue for an MDB that is converted from A97 to A2000 (the original references are retained), but only for newly-created MDBs. And even that is no big deal -- uncheck the ADO reference and add the DAO reference (if it's not already there -- can't remember it A2000 had both or just ADO).
 

boblarson

Smeghead
Joined
Jan 12, 2001
Messages
32,068
David and Dave:

Why are you guys responding to a spam post (spam in signature) which is tacked on to a post from 6 years ago? Did you bother to look at all at the things before starting to write a book on what to look for when upgrading from 97 to 2000?
 

dfenton

AWF VIP
Joined
May 22, 2007
Messages
469
Why are you guys responding to a spam post (spam in signature) which is tacked on to a post from 6 years ago? Did you bother to look at all at the things before starting to write a book on what to look for when upgrading from 97 to 2000?
Each day I come to this site and search for topics that have new posts in threads that include certain keywords. I failed to notice that the only recent post was one that is clearly not related to anything that came before.

I'm not sure I feel any responsibility for this. I added content to the topic that hadn't already been covered -- I just didn't notice the dates of that content. And several of my points were in regard to A2003, so I hope they might be helpful to someone converting to 2003 instead of 2000.

I don't think I owe anyone an apology for posting a reply in this thread.
 

boblarson

Smeghead
Joined
Jan 12, 2001
Messages
32,068
I never said you had to apologize for anything. I was just wondering why people were answering 6 year old threads.
 

gemma-the-husky

Super Moderator
Staff member
Joined
Sep 12, 2006
Messages
13,873
same thing as dave f, it was at the top of the list when i looked, and i just assume any thread is topical

it makes sense now you point it out tho, that the question was about upgrading to Access2000
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Top Bottom