Different version Access

[accessuser]

I have a database and experiencing some version reference problem. I created
the database in Access 2000 file format and Version @2002. My work computers
versions are 2000 and 2003. I want to know if there is a code that I can run
to tell the database to upgrade whatever the reference missing and fix it
automatically. We're planning to upgrade from 2000 to 2003 next year, and I
want to make my database will still work. What are the most common problems
for database in 2000 and upgrading to 2003. I have never done this before,
so please help me to explain it in a simple language if possible.


Thansk!

 

[Allen Browne]

There is no software that can automatically handle the differences between
references on different computers.

There are many thousands of libraries. If one is not present, the software
cannot know how to simulate that library. It cannot even handle different
versions of the same library.

The solution, therefore is to limit the libraries you use. The Access and
VBA libraries are required. Access will automatically select the correct
Access library when you switch versions, so you don't need to worry about
that. You probably want the DAO 3.6 Library also, but it is also standard
across Access 2000, 2002, and 2003, so there is no problem with that either.

If you want any others beyond those 3, it is your responsibility to ensure
that the correct version of the correct library is correctly registered on
each computer where you will use your software.

More info on libraries for each version of Access:
http://allenbrowne.com/ser-38.html

Aside from the library references, there are some other issues that arise as
you change versions. An MDB contains 2 versions of your code:
- the compiled version (what executes);
- the text version (what you view and edit.)
The compiled binary is different with every version of Access. So, when you
edit an MDB using different versions, Access is supposed to re-generate the
binary for the current version from the text. That process is flawed, and
you tend to get weird errors that make no sense and can be inconsistent. The
solution is to explicitly decompile the database whenever you switch to
developing on a different version.

To decompile, make a copy of the database, and enter something like this at
the command prompt while Access is not running. It is all one line, and
include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

 

[accessuser via AccessMonster.com]

Your link helped me to get rid of that "Can't find project or library"
message yesterday; it was very helpful. Thank you so much!!!!

Let me recap your message to make sure I got it right. As for the
"decompile" process, is the command prompt the same as the "Start, Run" and
copy the code you gave me? And when I change to work on a different computer
at work, i notice there is always on reference missing, control 1.0 something
like that, so i have to Shift Open the file run the Module, and uncheck the
missing reference. Do I have to go to all users desktop to make sure I
uncheck them so it wiill run correctly? Is there a way I can put a error msg
box instead having the access showing my users with VBA code page.

By the way, what are those projects or libraries for?

Thank you so much! I couldn't have gone this far without all the helps I
received from this site.

There is no software that can automatically handle the differences between
references on different computers.

There are many thousands of libraries. If one is not present, the software
cannot know how to simulate that library. It cannot even handle different
versions of the same library.

The solution, therefore is to limit the libraries you use. The Access and
VBA libraries are required. Access will automatically select the correct
Access library when you switch versions, so you don't need to worry about
that. You probably want the DAO 3.6 Library also, but it is also standard
across Access 2000, 2002, and 2003, so there is no problem with that either.

If you want any others beyond those 3, it is your responsibility to ensure
that the correct version of the correct library is correctly registered on
each computer where you will use your software.

More info on libraries for each version of Access:
http://allenbrowne.com/ser-38.html

Aside from the library references, there are some other issues that arise as
you change versions. An MDB contains 2 versions of your code:
- the compiled version (what executes);
- the text version (what you view and edit.)
The compiled binary is different with every version of Access. So, when you
edit an MDB using different versions, Access is supposed to re-generate the
binary for the current version from the text. That process is flawed, and
you tend to get weird errors that make no sense and can be inconsistent. The
solution is to explicitly decompile the database whenever you switch to
developing on a different version.

To decompile, make a copy of the database, and enter something like this at
the command prompt while Access is not running. It is all one line, and
include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

I have a database and experiencing some version reference problem. I
created

[quoted text clipped - 10 lines]

before,
so please help me to explain it in a simple language if possible.

 

[Allen Browne]

Yes, you can use Start | Run to fire off the decompile line.
I prefer to open a Command prompt, and paste it in there.
I also keep a little text document on my desktop containing most of that
command so I don't have to type the whole thing every time.

Libraries are code-add-ins that provide additional functionality. You can
create your own COM object programmed in C or some other language if you
wish, and add it in. Nice idea, but since any one missing library prevents
any code from running, they are actually a royal pain to manage, and a good
way to break your database.

If your Access database has an extra library (beyond the 3 basic ones) and
you don't know what it's for:
1. Open a code window, and verify that it compiles (Debug | Compile.)
2. Go to Tools | References, write down the name of the spurious library,
and uncheck it.
3. Compile again (Step 1.)
If it compiles after the library is unchecked, you probably don't need it.

--
Allen Browne - Microsoft MVP. Perth, Western Australia

Reply to group, rather than allenbrowne at mvps dot org.

Your link helped me to get rid of that "Can't find project or library"
message yesterday; it was very helpful. Thank you so much!!!!

Let me recap your message to make sure I got it right. As for the
"decompile" process, is the command prompt the same as the "Start, Run"
and
copy the code you gave me? And when I change to work on a different
computer
at work, i notice there is always on reference missing, control 1.0
something
like that, so i have to Shift Open the file run the Module, and uncheck
the
missing reference. Do I have to go to all users desktop to make sure I
uncheck them so it wiill run correctly? Is there a way I can put a error
msg
box instead having the access showing my users with VBA code page.

By the way, what are those projects or libraries for?

Thank you so much! I couldn't have gone this far without all the helps I
received from this site.

There is no software that can automatically handle the differences between
references on different computers.

There are many thousands of libraries. If one is not present, the software
cannot know how to simulate that library. It cannot even handle different
versions of the same library.

The solution, therefore is to limit the libraries you use. The Access and
VBA libraries are required. Access will automatically select the correct
Access library when you switch versions, so you don't need to worry about
that. You probably want the DAO 3.6 Library also, but it is also standard
across Access 2000, 2002, and 2003, so there is no problem with that
either.

If you want any others beyond those 3, it is your responsibility to ensure
that the correct version of the correct library is correctly registered on
each computer where you will use your software.

More info on libraries for each version of Access:
http://allenbrowne.com/ser-38.html

Aside from the library references, there are some other issues that arise
as
you change versions. An MDB contains 2 versions of your code:
- the compiled version (what executes);
- the text version (what you view and edit.)
The compiled binary is different with every version of Access. So, when
you
edit an MDB using different versions, Access is supposed to re-generate
the
binary for the current version from the text. That process is flawed, and
you tend to get weird errors that make no sense and can be inconsistent.
The
solution is to explicitly decompile the database whenever you switch to
developing on a different version.

To decompile, make a copy of the database, and enter something like this
at
the command prompt while Access is not running. It is all one line, and
include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

I have a database and experiencing some version reference problem. I
created

[quoted text clipped - 10 lines]

before,
so please help me to explain it in a simple language if possible.

 

[accessuser via AccessMonster.com]

so in this case, I will have my first MDB in 2000 and then follow your steps
in the 2003 version and save it in 2003 version. Then I will make 2003
version MDE and distrube 2003 MDE to 2003 users. Is that correct? It seems
like too many MDB and MDE copies and my database might corrupt anytime with
all the different versions going on at work. What is the best way to solve
this problem?

Thanks!

Yes, you can use Start | Run to fire off the decompile line.
I prefer to open a Command prompt, and paste it in there.
I also keep a little text document on my desktop containing most of that
command so I don't have to type the whole thing every time.

Libraries are code-add-ins that provide additional functionality. You can
create your own COM object programmed in C or some other language if you
wish, and add it in. Nice idea, but since any one missing library prevents
any code from running, they are actually a royal pain to manage, and a good
way to break your database.

If your Access database has an extra library (beyond the 3 basic ones) and
you don't know what it's for:
1. Open a code window, and verify that it compiles (Debug | Compile.)
2. Go to Tools | References, write down the name of the spurious library,
and uncheck it.
3. Compile again (Step 1.)
If it compiles after the library is unchecked, you probably don't need it.

Your link helped me to get rid of that "Can't find project or library"
message yesterday; it was very helpful. Thank you so much!!!!

[quoted text clipped - 66 lines]

 

[Allen Browne]

You have users on A2000 and 2003, but you develop in 2003 using the A2000
file format.

That's fine. When you are ready to release an MDE to users:
a) Decompile and compact in A2003.
b) Take the MDB to a machine that has A2000, and create the MDE.

You have:
- just one MDB (the one you are developing), and
- just one MDE (the current version that you distribute to all users - A2000
and A2003.)

--
Allen Browne - Microsoft MVP. Perth, Western Australia

Reply to group, rather than allenbrowne at mvps dot org.

so in this case, I will have my first MDB in 2000 and then follow your
steps
in the 2003 version and save it in 2003 version. Then I will make 2003
version MDE and distrube 2003 MDE to 2003 users. Is that correct? It
seems
like too many MDB and MDE copies and my database might corrupt anytime
with
all the different versions going on at work. What is the best way to
solve
this problem?

Thanks!

Yes, you can use Start | Run to fire off the decompile line.
I prefer to open a Command prompt, and paste it in there.
I also keep a little text document on my desktop containing most of that
command so I don't have to type the whole thing every time.

Libraries are code-add-ins that provide additional functionality. You can
create your own COM object programmed in C or some other language if you
wish, and add it in. Nice idea, but since any one missing library prevents
any code from running, they are actually a royal pain to manage, and a
good
way to break your database.

If your Access database has an extra library (beyond the 3 basic ones) and
you don't know what it's for:
1. Open a code window, and verify that it compiles (Debug | Compile.)
2. Go to Tools | References, write down the name of the spurious library,
and uncheck it.
3. Compile again (Step 1.)
If it compiles after the library is unchecked, you probably don't need it.

Your link helped me to get rid of that "Can't find project or library"
message yesterday; it was very helpful. Thank you so much!!!!

[quoted text clipped - 66 lines]

before,
so please help me to explain it in a simple language if possible.

 

[accessuser via AccessMonster.com]

Thank you Soooooo much Allen. I really appreciate you taking the time to
read and reply; it really helped me a lot.

You have users on A2000 and 2003, but you develop in 2003 using the A2000
file format.

That's fine. When you are ready to release an MDE to users:
a) Decompile and compact in A2003.
b) Take the MDB to a machine that has A2000, and create the MDE.

You have:
- just one MDB (the one you are developing), and
- just one MDE (the current version that you distribute to all users - A2000
and A2003.)

so in this case, I will have my first MDB in 2000 and then follow your
steps

[quoted text clipped - 33 lines]