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.

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

 

[Tony Toews]

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.

However you really want to put the FE on each machine or place in a
user specific directory on the server. This will help avoid some
weird error messages when users are changing the same forms record
source, filters and such as well as corruptions. It is also much
easier to implement a new version of the database with changed
queries, forms, reports and VBA code.

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version. For more info on the errors or the Auto FE
Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server. Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Albert D. Kallal]

You have some good tips here already.

I can only add that EVEN if you are working on a application that is SINGLE
user, you STILL need a way to send updates to that customer. the approach
you use should mean that YOU do not have to see, use, or have access to the
customers data files..

I have customers using my software in other cities, in fact, even other
counties. These customers have NEVER seen me in person, and yet I frequent
send them updates to their software. Some of these customers are single
user, and some of the customers are in a multi-user environment.

So, you need to split you application into data and software parts. This
will allow you to deploy new versions of your software to those end users
WITHOUT having to modify, copy, or touch the data part. All, kinds of
software you purchase now does come out with bug fixes, and updates...and
you can do the same...

I explain in detail the whole concept of splitting here:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

the only thing the above article leaves out is that you will need some code
to update, or modify the back end data files if you new release makes any
changes to the tables/data structures.

 

[Larry Daugherty]

So long as all of the users are using a single back end you've already
got a major part of your process under control.

Lots of "Access" problems aren't Access problems at all. They are
personal, people, political, organizational and a host of other kinds
of problems. That sounds like the case here.

The fact that you are making frequent changes to the table designs
means that you haven't yet got a good design for the application.
That can be the most difficult part of getting an application under
control, particularly where you've already released the product to
your users. They're using it and can't do without it. However, I
doubt that anyone will die if your change response is less than
immediate.

I suggest that you do some or all of the below suggestions to get
control of the process:

Stop making ad hoc changes and spending lots of time shifting the
data. You'll always have a data issue when you change the tables so
keep the frequency of those changes to a minimum. Get the cooperation
of your users and management. Hold regular structured in meetings
with your users to get their feedback. Put out the word when you'll
next be executing an upgrade. Invite people to have their change
requests in so that they can be discussed at the next meeting (before
the announced "next change date) so that everyone hears the rationale
for changes and issues between users can get cleared in a meeting
rather than in your making dithering changes. To lend urgency to
people getting their issues in before that meeting, announce that you
will read off a list of things that will go into the next change.
You'll add things agreed on by consensus at that meeting. Nothing
else will go into the current changes and the next change date will
not be before (pick some comfortably distant date). By doing the
foregoing you change the ratio of time spent in implementing changes
versus time spent migrating data.

One other thing you should do that should have been done before you
started writing the code: Analyze the application. Get to know what
problems exist that your application is supposed to ease or solve
completely. Get to know what the users do at each stage in the
current process and give some thought as to how you might re-design
the process to make it better. Understand the entities in play (your
tables should each hold all of a single entity type in your
application) and how various parts of the process modify data
contained in the entity record. [Weakness in this issue is what leads
to continual changes to table design]. Once your tables are correct
getting all of the rest of your application to play properly is
relatively easy. Keep changing your tables and you have to match
those changes in Forms and Reports and their Queries. That's a lot of
work!

HTH

 

[Smartin]

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.

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

This is great stuff -- great answers to a great question. Watching this
space...

 

[JustinP]

I agree Smartin, the good range of advice given is greatly appreciated.
To sum up what was said:

- Get clear on user requirements.

This has been an ongoing battle with this project. It's new territory
the team the is venturing into and thus having to learn things on the
way. I have a documentation trail that they use to for bugs,
enhancements, and feedback and that seems to work ok, but they often
they just don't know what the next stage is till they get there. The
nature of beast this time around. I'll take your advice Larry and see
what can be changed.

- Split the database.

I was already starting to look at the possibility of linking data
stored in SQL Server to the front end (anyone have any particular
experiences with this worth mentioning?)

- Automate the process

This will obviously speed things up and make it easier.

- Minimise data handling

Something I have been feeling a bit dubious about the whole time. It
never has seemed normal to be moving the key tables of the database
around all the time.


If you have any further experiences or comments on the above,
particularly potential mistakes, please mention them. Much appreciated.

 

[Albert D. Kallal]

- Split the database.

I was already starting to look at the possibility of linking data
stored in SQL Server to the front end (anyone have any particular
experiences with this worth mentioning?)

Just to be clear, the recommendation to split the database does NOT mean to
use sql server.
(it is not clear if you are just considering sql server, or you are not
clear on the suggestion to split - splitting has NOTHING to do with sql
sever, but a split application is usually somewhat easier to migrate to work
with sql server when the time comes..

 

[JustinP]

Albert,

I was aware the a splitting the database was a general term.

a split application is usually somewhat easier to migrate to work
with sql server

How is it easier?

 

[Guest]

Justin

To automatically update the back end file with new fields and tables have a
look at the BE Update Utility.mdb at -

http://www.rogersaccesslibrary.com/OtherLibraries.asp#Hibbs,Peter S

--
Peter Hibbs

Albert,

I was aware the a splitting the database was a general term.

a split application is usually somewhat easier to migrate to work
with sql server

How is it easier?

 

[Larry Daugherty]

Splitting the database makes your life easier because most of the
maintenance activity and enhancements will only affect the front end -
the Forms, Queries, Reports. If you find yourself continually
changing the design of the tables that means you still don't have a
good handle on your over all application. Occasional table changes
are inevitable.

By using the referenced FE Updater scheme you simply make your changes
to the front end, place it in its proper location and automation takes
care of the rest of it. Imagine having to do it in some less
automated way.

HTH
--
-Larry-
--

Albert,

I was aware the a splitting the database was a general term.

a split application is usually somewhat easier to migrate to work
with sql server

How is it easier?

 

[Albert D. Kallal]

a split application is usually somewhat easier to migrate to work

How is it easier?

It is somewhat easier, since then you will have been developign an
applcaiton (mdb) that does not have any tables in it. That means that your
design(s) likey would advoid creating temp tables for no reason at all. It
would also mean that you as a devleper are thinking in terms of a
applcation, and that the tables are a seperate thing. This "thinking" and
approach to develpumet transfers rather well to sql server.

While the concept of a split database is not difficult, at first, some
people do have to go through a bit of a mindset change. IF you gone through
this cahnge, then using a mdb + linked tables to sql server will be LITTLE
of a mindset change from using a back end mdb.

If you have to learn about splitting + sql server + how to udpate your
software + using a mde all in one shot, it is bi

So, , and also just means

 

[Albert D. Kallal]

opps...bumped send key....

How is it easier?

It is somewhat easier, since then you will have been developing an
application (mdb) that does not have any tables in it. That means that your
design(s) likely would avoid creating temp tables for no reason at all. It
would also mean that you as a developer are thinking in terms of a
application, and that the tables are a separate thing. This "thinking" and
approach to development transfers rather well to sql server.

While the concept of a split database is not difficult, at first, some
people do have to go through a bit of a mindset change. IF you gone through
this change, then using a mdb + linked tables to sql server will be LITTLE
of a mindset change from using a back end mdb.

If you have to learn about splitting + sql server + how to update your
software + using a mde all in one shot, it is bit much

So, a split database just means you are farther up the learning curve. If
you been running a split database, then you simply move the back end data to
sql server, and then relink/point your front end links to sql server. When
you do this, about 95% of the code and forms you have now will work....