Upgrading 97 to 2003 - Is a Consultant Needed?

[Smartin]

My Company is planning to upgrade MSOffice from 97 to 2003 this year. We
make fairly extensive use of Access 97 databases to support departmental
needs, having on the order of 50 MDB's in regular use.

I heard on the grapevine that the Company is planning to hire a
consultant to assist in the migration to upgrade all the MDB files.
Before my time, the Company endured other upgrades... from Win3.1 to 95,
and from Filemaker to Access, without outside assistance. My thoughts
are a few of us are reasonably skilled Access users, A2003 makes
conversion easy with the built-in wizard, we have analyzed our pool of
MDB's with Microsoft's Conversion Toolkit (with no issues revealed), and
the MDB's we use are not "production" in the sense that they do not
directly support the Company's operations.

Question for the community: does hiring a consultant seem like overkill?
Are the risks severe enough to warrant this?

For what it's worth, the vast majority of the MDB's we have make use of
forms, reports, hand-written queries, and macros. A much smaller number
have hand-written VBA standard modules and class modules.

All input is welcome. Thanks!
--
Smartin

[Rick Brandt]

"Smartin" <sm********@yahoo.com> wrote in message
news:q8******************************@giganews.com ...

My Company is planning to upgrade MSOffice from 97 to 2003 this year. We make
fairly extensive use of Access 97 databases to support departmental needs,
having on the order of 50 MDB's in regular use.

I heard on the grapevine that the Company is planning to hire a consultant to
assist in the migration to upgrade all the MDB files. Before my time, the
Company endured other upgrades... from Win3.1 to 95, and from Filemaker to
Access, without outside assistance. My thoughts are a few of us are reasonably
skilled Access users, A2003 makes conversion easy with the built-in wizard, we
have analyzed our pool of MDB's with Microsoft's Conversion Toolkit (with no
issues revealed), and the MDB's we use are not "production" in the sense that
they do not directly support the Company's operations.

Question for the community: does hiring a consultant seem like overkill? Are
the risks severe enough to warrant this?

For what it's worth, the vast majority of the MDB's we have make use of forms,
reports, hand-written queries, and macros. A much smaller number have
hand-written VBA standard modules and class modules.

All input is welcome. Thanks!

In general...If you have a "healthy" Access 97 app meaning you can compile all
modules without errors and you can successfully create an MDE out of it without
errors then it should convert over to Access 2003 without incident and just
work.

There are a few differences and "gotchas" any time you do stuff like this, but I
agree that a consultant is a bit over the top.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[(PeteCresswell)]

Per Smartin:

Question for the community: does hiring a consultant seem like overkill?
Are the risks severe enough to warrant this?

That's a tough question because nobody knows the relative expertise levels of
the in-house people and whatever "consultant" they'll put on the case.

Quotes because I've cleaned up after several big consulting firms'
"consultants". In those cases, it looked to me like the parent firm sent in the
MBA's in pin-stripe suites to get the contract, and then billed a couple hundred
bucks an hour for some kid fresh out of college who claimed VB experience....but
(judging from the code) had never written an MS Access app.

OTOH, maybe the in-house folks have been developing apps mainly via wizards and
the consultant you'll get has been writing MS Access apps in a demanding
environment for over 10 years.

Seems like it could go either way or about a lot of ways in-between.
--
PeteCresswell

[Allen Browne]

Run the conversion Toolkit over the more invovled of your databases. If can
understand any issues it highlights, you probably do not need a consultant.

More info on the kinds of things you might need to know:
Converting from Access 97 to 2000, 2002 or 2003
at:
http://allenbrowne.com/ser-48.html

--
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.

"Smartin" <sm********@yahoo.com> wrote in message
news:q8******************************@giganews.com ...

My Company is planning to upgrade MSOffice from 97 to 2003 this year. We
make fairly extensive use of Access 97 databases to support departmental
needs, having on the order of 50 MDB's in regular use.

I heard on the grapevine that the Company is planning to hire a consultant
to assist in the migration to upgrade all the MDB files. Before my time,
the Company endured other upgrades... from Win3.1 to 95, and from
Filemaker to Access, without outside assistance. My thoughts are a few of
us are reasonably skilled Access users, A2003 makes conversion easy with
the built-in wizard, we have analyzed our pool of MDB's with Microsoft's
Conversion Toolkit (with no issues revealed), and the MDB's we use are not
"production" in the sense that they do not directly support the Company's
operations.

Question for the community: does hiring a consultant seem like overkill?
Are the risks severe enough to warrant this?

For what it's worth, the vast majority of the MDB's we have make use of
forms, reports, hand-written queries, and macros. A much smaller number
have hand-written VBA standard modules and class modules.

All input is welcome. Thanks!
--
Smartin

[david epsom dot com dot au]

Convert all 50 MDB's first. If you have any issues, then
you will know if you need a consultant.

If you can't afford to have your Access applications
not working for a couple of days, then you probably
shouldn't be using Access.

I'm not saying that as an Access critic. MS markets
other products for building high availability
applications.
(david)

"Smartin" <sm********@yahoo.com> wrote in message
news:q8******************************@giganews.com ...

My Company is planning to upgrade MSOffice from 97 to 2003 this year. We
make fairly extensive use of Access 97 databases to support departmental
needs, having on the order of 50 MDB's in regular use.

I heard on the grapevine that the Company is planning to hire a consultant
to assist in the migration to upgrade all the MDB files. Before my time,
the Company endured other upgrades... from Win3.1 to 95, and from
Filemaker to Access, without outside assistance. My thoughts are a few of
us are reasonably skilled Access users, A2003 makes conversion easy with
the built-in wizard, we have analyzed our pool of MDB's with Microsoft's
Conversion Toolkit (with no issues revealed), and the MDB's we use are not
"production" in the sense that they do not directly support the Company's
operations.

Question for the community: does hiring a consultant seem like overkill?
Are the risks severe enough to warrant this?

For what it's worth, the vast majority of the MDB's we have make use of
forms, reports, hand-written queries, and macros. A much smaller number
have hand-written VBA standard modules and class modules.

All input is welcome. Thanks!
--
Smartin

[Smartin]

Thanks again for your input. I appreciate you sharing your insights.
Food for thought is a wonderful thing.

--
Smartin

[corey lawson]

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:56******************@newssvr29.news.prodigy.n et:

"Smartin" <sm********@yahoo.com> wrote in message
news:q8******************************@giganews.com ...

My Company is planning to upgrade MSOffice from 97 to 2003 this year.
We make fairly extensive use of Access 97 databases to support
departmental needs, having on the order of 50 MDB's in regular use.

In general...If you have a "healthy" Access 97 app meaning you can
compile all modules without errors and you can successfully create an
MDE out of it without errors then it should convert over to Access
2003 without incident and just work.

There are a few differences and "gotchas" any time you do stuff like
this, but I agree that a consultant is a bit over the top.

The biggest gotcha from A97->A2000 (and consequently, A2K3) is with DAO
objects. By default, DAO is *NOT* referenced in A2000. Your code will
gloriously not recompile in A2000 until you reference the DAO 3.60
library. But it also has ADO referenced by default, too. So if your A97
code is full of "Dim rs as Recordset", you'll probably want to do a
global search-and-replace of "as Recordset" to "as DAO.Recordset", or
again, even if you reference DAO (as well as ADO), your code will
gloriously not compile because of all the method errors in the
DAO.Recordset's namespace that are probably in your code but are not in
the ADODB.Recordset's namespace or have different parameter signatures,
because A2K/A2K3 will try to find them in the ADODB namespace first, not
DAO, even if both libraries are referenced.

On the plus side, in the future, it *is* possible to make your code check
the references and reference a library before the code actually runs it
in A2K/A2k3. Even though the functions are in A97's VBA, there's a
compile in the process of running VBA code in A97 which will barf on code
that uses a library that isn't yet referenced, even if you're trying to
reference the library programmatically.

So let's say you have a function that calls a bunch of DAO objects. It is
now possible to add defensive code something like this:

Sub MyDAOCode
if not IsReferenced("DAO") then
SetReference("Microsoft Data Access Objects 3.60")
end if

Dim rs as DAO.Recordset
....
end sub

Or, if you have a startup form in your app, just make these calls in that
form's OnOpen event handler.

[david epsom dot com dot au]

When you upgrade from A97 to A2K, your references are
retained, no ADO references is added, and your DAO
reference is updated to DAO 3.6.

So your DAO reference remains, and there is no ADO reference.

The application.references methods and properties
are in A97 as well as A2K.

The code you offer is unlikely to work in either
A2K or A97, because code will crash immediately
if a reference is missing.

also...

I post here all the time, and I make frequent errors
of fact and omission, which I learn from. I don't
mean to discourage you. (I wish I could say that better).

(david)
"corey lawson" <corey.lawson@worldnetdotattdotnet> wrote in message
news:Xn********************************@127.0.0.1. ..

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:56******************@newssvr29.news.prodigy.n et:

"Smartin" <sm********@yahoo.com> wrote in message
news:q8******************************@giganews.com ...

My Company is planning to upgrade MSOffice from 97 to 2003 this year.
We make fairly extensive use of Access 97 databases to support
departmental needs, having on the order of 50 MDB's in regular use.

In general...If you have a "healthy" Access 97 app meaning you can
compile all modules without errors and you can successfully create an
MDE out of it without errors then it should convert over to Access
2003 without incident and just work.

There are a few differences and "gotchas" any time you do stuff like
this, but I agree that a consultant is a bit over the top.

The biggest gotcha from A97->A2000 (and consequently, A2K3) is with DAO
objects. By default, DAO is *NOT* referenced in A2000. Your code will
gloriously not recompile in A2000 until you reference the DAO 3.60
library. But it also has ADO referenced by default, too. So if your A97
code is full of "Dim rs as Recordset", you'll probably want to do a
global search-and-replace of "as Recordset" to "as DAO.Recordset", or
again, even if you reference DAO (as well as ADO), your code will
gloriously not compile because of all the method errors in the
DAO.Recordset's namespace that are probably in your code but are not in
the ADODB.Recordset's namespace or have different parameter signatures,
because A2K/A2K3 will try to find them in the ADODB namespace first, not
DAO, even if both libraries are referenced.

On the plus side, in the future, it *is* possible to make your code check
the references and reference a library before the code actually runs it
in A2K/A2k3. Even though the functions are in A97's VBA, there's a
compile in the process of running VBA code in A97 which will barf on code
that uses a library that isn't yet referenced, even if you're trying to
reference the library programmatically.

So let's say you have a function that calls a bunch of DAO objects. It is
now possible to add defensive code something like this:

Sub MyDAOCode
if not IsReferenced("DAO") then
SetReference("Microsoft Data Access Objects 3.60")
end if

Dim rs as DAO.Recordset
...
end sub

Or, if you have a startup form in your app, just make these calls in that
form's OnOpen event handler.

[Rick Brandt]

corey lawson wrote:

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:56******************@newssvr29.news.prodigy.n et:

"Smartin" <sm********@yahoo.com> wrote in message
news:q8******************************@giganews.com ...

My Company is planning to upgrade MSOffice from 97 to 2003 this
year. We make fairly extensive use of Access 97 databases to
support departmental needs, having on the order of 50 MDB's in
regular use.

In general...If you have a "healthy" Access 97 app meaning you can
compile all modules without errors and you can successfully create
an MDE out of it without errors then it should convert over to
Access 2003 without incident and just work.

There are a few differences and "gotchas" any time you do stuff like
this, but I agree that a consultant is a bit over the top.

The biggest gotcha from A97->A2000 (and consequently, A2K3) is with
DAO objects. By default, DAO is *NOT* referenced in A2000. Your code
will gloriously not recompile in A2000 until you reference the DAO
3.60 library. [snip]

This does not apply to *converted* apps. They end up with a DAO reference and
without an ADO reference just like they were in A97. A2003 also now has a
reference to DAO so your points only apply to creating new apps in A2000 or
A2002.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com