Design/Deployment Strategy

[Tom]

I’d like to solicit some advice on a design/deployment strategy before
I start a project. Any thoughts would be appreciated.

Current situation:
Users have a mix of the full version of Access2003/2002/2000 or the
runtime version of Access2000. Standardized startup .bat file checks
to see which version is installed, copies a master db file to a local
hard drive, runs access and starts the local copy of the db. DBs
point to a SQL Server back end.

As the developer I work in Access2003 and have access to a machine
with Access2000 for making the .mde file.

Corporate IT has advised that we are upgrading to Office2007 in the
near future. Access2007 WILL NOT installed by default, although it
will be “freely” available if asked for by a user. Corporate IT has
not stated if they are going to automatically upgrade all
Access2000/2002/2003 users to Access2007, or if they are going to
leave those installations alone.

Opportunity to Excel!
I have been tasked with redeveloping an aging database to make it play
nice with other upgraded software, incorporate new policies, etc. My
dilemma is deciding which version of Access to develop in and deciding
on a deployment strategy. Do I:
1. Develop in Access2003, deploy as an Access2000 compatible .mde and
hope that the ribbon interface in Access2007 doesn’t make hash of my
efforts?
2. Develop and deploy in Access2007 and trust that IT will stick to
their deployment schedule, and force everybody to upgrade?
3. Develop for both the menu system in Access2003 and earlier and the
ribbon in Access2007 and chalk the added cost and maintenance burden
up to the price of flexibility?
4. Recommend IT implement a Terminal Server/Citrix solution so I can
control which version of Access is used (and then develop in
Access2007)?

I’m leaning towards Option 4 so I can remove some variables from
consideration. The downside is that I am ceding control over some
portion of the app to people that don’t necessarily consider it a
priority (and its outside my comfort zone, although it seems to be
straight forward enough).

Any thoughts?

Thanks - Tom

 

[Mark Andrews]

I would stick with Access2000 and then switch to Access2007 when you think
you won't have any troubles with users being able to get the right software.
Assume you are going to change the databases a bit when you make the switch
so keep yourself up to speed on Access2007 new features and don't use
Access2000 features that are going away if you can avoid it.

Try and get any Access2002 users to switch to some other version.

Plan B would be to make the switch and make it known that you need
Access2007 to run the database.

I wouldn't jump into terminal services unless you needed that to make things
work (WAN situation etc...).

Just my opinion,
Mark

I’d like to solicit some advice on a design/deployment strategy before
I start a project. Any thoughts would be appreciated.

Current situation:
Users have a mix of the full version of Access2003/2002/2000 or the
runtime version of Access2000. Standardized startup .bat file checks
to see which version is installed, copies a master db file to a local
hard drive, runs access and starts the local copy of the db. DBs
point to a SQL Server back end.

As the developer I work in Access2003 and have access to a machine
with Access2000 for making the .mde file.

Corporate IT has advised that we are upgrading to Office2007 in the
near future. Access2007 WILL NOT installed by default, although it
will be “freely” available if asked for by a user. Corporate IT has
not stated if they are going to automatically upgrade all
Access2000/2002/2003 users to Access2007, or if they are going to
leave those installations alone.

Opportunity to Excel!
I have been tasked with redeveloping an aging database to make it play
nice with other upgraded software, incorporate new policies, etc. My
dilemma is deciding which version of Access to develop in and deciding
on a deployment strategy. Do I:
1. Develop in Access2003, deploy as an Access2000 compatible .mde and
hope that the ribbon interface in Access2007 doesn’t make hash of my
efforts?
2. Develop and deploy in Access2007 and trust that IT will stick to
their deployment schedule, and force everybody to upgrade?
3. Develop for both the menu system in Access2003 and earlier and the
ribbon in Access2007 and chalk the added cost and maintenance burden
up to the price of flexibility?
4. Recommend IT implement a Terminal Server/Citrix solution so I can
control which version of Access is used (and then develop in
Access2007)?

I’m leaning towards Option 4 so I can remove some variables from
consideration. The downside is that I am ceding control over some
portion of the app to people that don’t necessarily consider it a
priority (and its outside my comfort zone, although it seems to be
straight forward enough).

Any thoughts?

Thanks - Tom