By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,689 Members | 1,759 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,689 IT Pros & Developers. It's quick & easy.

Access Development 2000 versus 2002/3

P: n/a
Morning All

I have been developing and deploying with Office 2000 for about 3 years, mainly Access based
programs and although I have gotten used to it's quirks, I am starting to feel that I should be
switching to Office 2002 or maybe 2003

It would mean upgrading a lot of existing work, not to mention 3rd party tools that I have bought
over the years. I'll switch if there are any real benefits but if it is just marginally better I'll
stick with 2000. Most of my programs are running on "Stand alone computers" or small networks of
less than 3 Machines.

Another thing I would like to know is, has the Package and Deployment tool been improved in the
later versions, or would I be better off using some third party tool like Wise Installations. What
are the benefits and drawbacks here??

All comments gratefully appreciated

Stickleback
Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
I believe Access 2002, with the current 3 Service Packs is better than
Access 2000 with its current 3 Service Packs. From those much more
knowledgeable about ADPs than I, I understand that the area of ADP (Access
Projects) are one of the major areas of improvement. There are a good many
others... I think a little searching at http://www.microsoft.com/office
would lead you to a list.

The good news is that, with those 3 Service Packs/Releases, Access 2000 _is_
usable and relatively stable, not nearly so buggy as it was earlier in its
lifecycle.

If that list of enhancements is for Access 2003, don't worry, because there
were relatively few Access-specific changes from 2002 to 2003. The big
change, and one generally not liked by Access folks, is the user interface
for Help -- for example, the very useful Index tab is no longer available in
Office 2003 Help.

I keep both Access 97 and Access 2002 on my machine, along with Access 2003,
in large part so I can go back and use the better (IMNSHO) Help.

Larry Linson
Microsoft Access MVP
"Stickleback" <St*********@hotmail.com> wrote in message
news:8g********************************@4ax.com...
Morning All

I have been developing and deploying with Office 2000 for about 3 years, mainly Access based programs and although I have gotten used to it's quirks, I am starting to feel that I should be switching to Office 2002 or maybe 2003

It would mean upgrading a lot of existing work, not to mention 3rd party tools that I have bought over the years. I'll switch if there are any real benefits but if it is just marginally better I'll stick with 2000. Most of my programs are running on "Stand alone computers" or small networks of less than 3 Machines.

Another thing I would like to know is, has the Package and Deployment tool been improved in the later versions, or would I be better off using some third party tool like Wise Installations. What are the benefits and drawbacks here??

All comments gratefully appreciated

Stickleback

Nov 12 '05 #2

P: n/a
On Fri, 30 Apr 2004 03:26:31 GMT, "Larry Linson" <bo*****@localhost.not>
wrote:
I believe Access 2002, with the current 3 Service Packs is better than
Access 2000 with its current 3 Service Packs. From those much more
knowledgeable about ADPs than I, I understand that the area of ADP (Access
Projects) are one of the major areas of improvement. There are a good many
others... I think a little searching at http://www.microsoft.com/office
would lead you to a list.


Personally, having worked with both MDBs and ADPs, I would agree that Access
2002 is a great improvement with MDBs, but whether it is an improvement for
ADPs is very debatable. Some ADP bugs fixed in Access 2000 have been
re-broken in 2002, and never fixed again, and many new bugs were also
introduced and not fixed. Currently, TIMESTAMP support is fixed in 2000, but
not 2002, and many multi-table queries are editable in 2000, and not in 2002.
A few new ADP capabilities have been added including support for SQL Server
2000 user defined functions, but most new features are not documented, and
many are of dubious benfit.

Of course,ADPs are also, IMO (others differ on this) not useful for anything
but prototyping, though they are very nice for prototyping. I would worry
more about MDBs than ADPs, and for that, Access 2002 is head and shoulders
above Access 2000.

With respect to Access 2003, from what I've heard, the only things they've
added are a slightly more powerful XML support, and a useless 1/2 way
implementation of smart tags. No bugs have been fixed, performance is slower,
and a few new bugs have been introduced. i see absolutely nothing compelling
about Access 2003 as it stands now. Now that the task of getting Office 2003
out the door is over, it would not surprise me if a really significant service
pack makes 2003 much better in the near future, but I have no proof of that.

Nov 12 '05 #3

P: n/a
"Larry Linson" <bo*****@localhost.not> wrote in
news:HH********************@nwrddc01.gnilink.net:
I believe Access 2002, with the current 3 Service Packs is better
than Access 2000 with its current 3 Service Packs. From those much
more knowledgeable about ADPs than I, I understand that the area
of ADP (Access Projects) are one of the major areas of
improvement. There are a good many others... I think a little
searching at http://www.microsoft.com/office would lead you to a
list.

The good news is that, with those 3 Service Packs/Releases, Access
2000 _is_ usable and relatively stable, not nearly so buggy as it
was earlier in its lifecycle.


So far as I can tell, Access 2K as worked OK since SR1a. The later
service releases neuter Outlook attachments in ways that most of my
clients have avoided (until recently). Basically, nowadays, I can't
email any attachments to any of my clients who use Outlook for
email. This is a ridiculous situation, of course.

On the question of A2K2, I spent my first time with it yesterday,
and I must say I'm simply underwhelmed. It's nice to be able to open
subreports/subforms independently, but it would be better if I could
set that as the default, instead of having to do extra work for it.

The main thing that annoyed me about it is that the monolithic save
in A2K2 is slower than A2K. Now, this may have been because the file
I was working on includes a number of graphics, but I've worked in
20MB MDBs before, and never been annoyed by the save time (except in
the original A2K).

The printer object is a nice thing, but there's a fatal bug that
seems to me to make it a necessity to use it, in that report
settings changed in preview mode get saved even when you don't
explicitly save them:

http://support.microsoft.com/default...b;en-us;282363

The project I was brought in on was to try to fix a printing
problem, and it seems there's no way around it, especially because
custom printer properties specific to a specific driver do not seem
to be exposed through the printer object.

Yes, it's easier than parsing those arrays, but it certainly wasn't
a silver bullet for a runtime project converted from A97 that then
developed the inability to print properly.

The client is going to abandon Access for this project because of
it. Of course, if they'd just gotten the SageKey scripts for the old
A97 runtime, they'd have had no such problems, but their developer
didn't know about that until after they'd made the commitment to the
conversion.

It does raise the question for me: why do I know about things that
I've never used (I've never once created a runtime distribution)?
It's all because I read this newsgroup. This provides a real
competitive advantage, because I know the landscape even of those
areas of Access in which I lack firsthand experience.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.