From Version 97 to 2003

J

JD

We are upgrading our Office 97 to Office 2003 company wide - pushing it out
via SMS.

Now, we have developers who created some codes for some Excel 97
applications and Access 97 - since we are going to Office 2003 - WHAT are
some things should we be aware of, and some things to look for? What is the
main thing new in terms of the code / macros our developers have created to
be aware of?

Thank you.
 
A

Allen Browne

There are many unresolved problems in the last 3 versions of Access. The
real cost over the next 18 months will be several weeks worth of
wages/contract fees for each developer, as they hit the problems, learn the
new stuff, and learn the workarounds for the bugs.

A few examples:

1. Security Debacle
Every time you open your databaes in A2003, you face a ridiculous series of
warnings that opening your database is an unsafe thing to do!!! If you have
installed the JET 4 SP8 library but not enabled Sandbox mode, you have to
navigate through *3* dialogs for every file you open, reading what question
you are answering (hidden in the middle of large dialog) and choosing the
non-default answers - just to get your file open! This has to qualify as the
stupidest idea that ever came out of Redmond for a desktop product.

The only practical workard is to set the Access security to Low. There is no
problem with that, but try explaining that to clients and managers - esp. as
MS specifically says it is "not recommended".

The other alternative is to buy a certificate, and keep paying fees every
year. This still doesn't work well during development, bloats the database,
and is not possible in practice for individual developers.

2. Name AutoCorrect
More than a dozen bugs with this "feature" (some fixed), as well as severe
performance and potential corruption issues. More info:
http://allenbrowne.com/bug-03.html

3. New/changed properties
Developing in A2003 takes more work because of new properties that have to
be disabled, and existing properties that have had their defaults changed.
More info and suggested workarounds:
http://allenbrowne.com/bug-09.html

4. Problems with JET 4
The DAO library you are used to working with has not been updated to support
most of the new features in Jet4. As a result, you have to learn ADO to work
with them, and some of them do not even work in the interface. Others do not
work properly, such as quite basic problems with the Decimal field type
described at:
http://allenbrowne.com/bug-08.html

5. Clashing libraries
Any code that refers to a Recordset, Field, or Property is likely to fail in
A2003. The ADO library also has objects with the same names, and defaults to
a higher priority, so your code won't work until you disambiguate, e.g.:
Dim rs As DAO.Recordset

6. Monolithic save
In Access 97, when you changed an object and saved, only the changed object
was saved. In A2000 and later, when you change any object, Access re-writes
them all. That means concurrency problems (2 people cannot work in different
objects in the same mdb at once), and it takes longer to save if the mdb has
many objects.

7. Loose coupling
Instead of the integrated development environment in A97, A2000 and later
have a version of Visual Basic cobbled together with the main Access window.
That's handy if you with with dual monitors, but does cause other problems
from minor annoyances with way the windows behave through to Access getting
completely confused about what goes with what if you have different versions
of Access open at the same time, thereby corrupting the database.

8 More bugs
Many of the known bugs in A97 have not been fixed. Hundreds more were
introduced in A2000, and many of those remain unfixed in A2003. In our
experience, you can expect to waste time with a couple of new bugs you have
not come across before in every mdb you develop. Some of these are listed
here:
http://members.iinet.net.au/~allenbrowne/tips.html#flaws
 
J

JD

Wow ! thanks for the extended response, sir!




Allen Browne said:
There are many unresolved problems in the last 3 versions of Access. The
real cost over the next 18 months will be several weeks worth of
wages/contract fees for each developer, as they hit the problems, learn the
new stuff, and learn the workarounds for the bugs.

A few examples:

1. Security Debacle
Every time you open your databaes in A2003, you face a ridiculous series of
warnings that opening your database is an unsafe thing to do!!! If you have
installed the JET 4 SP8 library but not enabled Sandbox mode, you have to
navigate through *3* dialogs for every file you open, reading what question
you are answering (hidden in the middle of large dialog) and choosing the
non-default answers - just to get your file open! This has to qualify as the
stupidest idea that ever came out of Redmond for a desktop product.

The only practical workard is to set the Access security to Low. There is no
problem with that, but try explaining that to clients and managers - esp. as
MS specifically says it is "not recommended".

The other alternative is to buy a certificate, and keep paying fees every
year. This still doesn't work well during development, bloats the database,
and is not possible in practice for individual developers.

2. Name AutoCorrect
More than a dozen bugs with this "feature" (some fixed), as well as severe
performance and potential corruption issues. More info:
http://allenbrowne.com/bug-03.html

3. New/changed properties
Developing in A2003 takes more work because of new properties that have to
be disabled, and existing properties that have had their defaults changed.
More info and suggested workarounds:
http://allenbrowne.com/bug-09.html

4. Problems with JET 4
The DAO library you are used to working with has not been updated to support
most of the new features in Jet4. As a result, you have to learn ADO to work
with them, and some of them do not even work in the interface. Others do not
work properly, such as quite basic problems with the Decimal field type
described at:
http://allenbrowne.com/bug-08.html

5. Clashing libraries
Any code that refers to a Recordset, Field, or Property is likely to fail in
A2003. The ADO library also has objects with the same names, and defaults to
a higher priority, so your code won't work until you disambiguate, e.g.:
Dim rs As DAO.Recordset

6. Monolithic save
In Access 97, when you changed an object and saved, only the changed object
was saved. In A2000 and later, when you change any object, Access re-writes
them all. That means concurrency problems (2 people cannot work in different
objects in the same mdb at once), and it takes longer to save if the mdb has
many objects.

7. Loose coupling
Instead of the integrated development environment in A97, A2000 and later
have a version of Visual Basic cobbled together with the main Access window.
That's handy if you with with dual monitors, but does cause other problems
from minor annoyances with way the windows behave through to Access getting
completely confused about what goes with what if you have different versions
of Access open at the same time, thereby corrupting the database.

8 More bugs
Many of the known bugs in A97 have not been fixed. Hundreds more were
introduced in A2000, and many of those remain unfixed in A2003. In our
experience, you can expect to waste time with a couple of new bugs you have
not come across before in every mdb you develop. Some of these are listed
here:
http://members.iinet.net.au/~allenbrowne/tips.html#flaws
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top