Re: Contemplating A97 to A2003

From: Allen Browne (AllenBrowne_at_SeeSig.Invalid)
Date: 02/08/05 

Date: Tue, 8 Feb 2005 16:46:49 +0800

Replies embedded. 

-- 
Allen Browne - Microsoft MVP.  Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Leslie Isaacs" <leslie.isaacs@gp-n85011.nhs.uk> wrote in message
news:%23tqZfUTDFHA.1836@tk2msftngp13.phx.gbl...
>
> Having read it all - and understood about half of it! - I'm somewhat put 
> off
> converting at all.
> Mainly it was the bit about "Learning Access is more difficult" - 
> interface,
> DAO and ADOX mean nothing to me, and as I'm not a professional developer 
> I'm
> unlikely to get to grips with it all.
You probably don't need to learn it all. If you are already coding in DAO, 
you can convert your database, and just continue to use DAO code. IMHO, 
that's still the best way to do it anyway if your data is in Access tables.
> My reasons for contemplating conversion are (were!):
>
> 1)  my assumptions that the later version would be more stable, less buggy
> and faster (call me naive?)
Correctly set up, A2003 is more stable than A97 to develop in. During heavy 
development, I expect a corruption every few days in A97, and every few 
weeks in A2003.
Once the development is complete (not adding or modifying forms, code, 
reports, etc), both versions are extremely stable. On reliable hardware with 
reliable power and a reliable network and reliable users, you could go for 
years and not see a corruption.
Performance-wise, most new versions are slower than older versions, and 
A2003 will be a little slower than A97, e.g. because of the Unicode support. 
Some things are much slower in A2003, e.g. VBA functions called in a query.
> 2)  my assumptions that the new features would be useful in establishing a
> web interface between my payroll agency (which uses the mdb) and our 
> clients
Although A2000 and later have Data Access Pages (DAPs), they are not very 
useful IME, certainly not beyond a local intranet. Better to use another 
technology such as PHP (or ASP) to read/write the Access database. Of 
course, none of these including DAPs give you the rich environment that 
makes Access such as joy to work with.
> 3) a developer whose services I would like to use for some small projects 
> no
> longer works with A97
Good people you can trust and work with - yes, that's a very important 
consideration.
> 4) the XML file format would be useful for Inland Revenue end-of-year
> returns
If you need XML support, then that's an important aspect as well.
> 5) a general, ill-defined but definite feeling that upgrade = progress =
> good
:-)
> ... Your initial reply (that I should be able to update with
> a minimum of fuss) was very encouraging, but the information in the link 
> had
> the opposite effect.
Leslie, I think there are 2 questions here:
1. How hard is it to learn to use A2003 so that it's usable?
Expect a bit of a learning curve, so you know how to:
- turn off the stuff that corrupts the database (e.g. Name AutoCorrect),
- get rid of the stuff that slows it to a crawl (e.g. Subdatasheets),
- work around the new bugs (e.g. an AccessField in the LinkChildFields),
- get used to the new frustrations (e.g. having to turn AllowZeroLength off 
every time you create a Text field),
- solve the interface problems (e.g. controls that flicker on tab controls),
and so on. These obstacles are not huge: we have come a long way since the 
days when A2000 was first released and we suggested not to use it.
2. How hard is it to convert an A97 database?
The answer is that once you have #1 down, this one is usually pretty simple. 
(There are exceptions: e.g if you database was originally written in Access 
2 and uses the 2.5/3/5 compatibility layer, you have work to do.)
Hope that clarifies it for you.