Version control, rolling out new versions...

[JustinP]

I am having to roll out a new version of the database I've designed
every few days (the changes are mostly to do with field additions
(tables and forms), and minor bug fixes. The users have a copy of the
database they work off, and I have a copy in another location that I
use to develop. When I roll out a new version (say, v1.1.3.1), I
usually have to wait till everyone has closed the database and I import
tables from their copy of the database and overwrite their copy with
the copy I have been developing. As you can tell, this is obviously the
work of an novice.

1. What processes (and/or database design changes) do you advise I take
to make this easier?

 

[James A. Fortune]

I am having to roll out a new version of the database I've designed
every few days (the changes are mostly to do with field additions
(tables and forms), and minor bug fixes. The users have a copy of the
database they work off, and I have a copy in another location that I
use to develop. When I roll out a new version (say, v1.1.3.1), I
usually have to wait till everyone has closed the database and I import
tables from their copy of the database and overwrite their copy with
the copy I have been developing. As you can tell, this is obviously the
work of an novice.

1. What processes (and/or database design changes) do you advise I take
to make this easier?

One thing you might want to consider, and I'm sure many will disagree,
is that you probably don't need to use, say, v1.1.3.1. If an Access
developer is working on a database that is long-term and updated
frequently, she can simply use the build date and time. That is
adequate to determine whether a new copy is needed. She doesn't have to
decide when a new version happens either. Another thing to consider is
whether or not a particular group of users is going to be affected by a
software revision. If I change only a time ticket entry form, there are
only a couple of users who are affected by the change. It's usually
good to update everyone after each revision, but it's possible to use a
linked table with the build date and time required for each group. When
the database is opened, the linked table can be checked against a local
table containing the current build information to see if the user has an
adequate version. A search of this newsgroup should turn up some Front
End (FE) autoupdate tools.

James A. Fortune
(e-mail address removed)

 

[Arvin Meyer [MVP]]

As the others have mentioned, split the database and have each front-end run
from the workstations. To roll out new versions you can use my free starter
database:

http://www.datastrat.com/Download/Starter.zip
--
Arvin Meyer, MCP, MVP
Free MS-Access downloads:
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

 

[aaron.kempf]

if you used Access Data Projects; you would keep all your tables and
fields and queries in one place.

it would make revisions a LOT easier.

Access MDB is for ****ing retards and babies.

Grow some balls, kid
Access Data Projects won the war.

-Aaron
ADP Nationalist