Delivering and Turning Over Support Responsibility for an Application

C

Chaim

I have to this point never actually delivered an Access app. I've seen
several checklists of things to do/procedures to follow prior to delivery,
and I certainly intend to follow that advice as appropriate for my
situation. One thing that I have looked for, though, and have not found is a
description of what an Access app 'looks like' when delivered. Should I
expect the Microsoft Access console window to appear? Can things be
configured so that it doesn't appear? (I know there are plenty of examples
out there, but in my environment at work I can't download them. And, in the
MS examples that I am allowed to download, I do not know if the console is
there because they want it to be there for there own tutorial-related
reasons or because it is essential to displaying the application.)

For that matter, what are best practices for organizing an application?
Right now, although I understand all of the code and how it relates to the
forms, etc., if I had to turn it over in short order I would have no good
idea how to arrange/rationalize this structure. In my C/C++ life, I capture
that info in Rose. In my DB life, I capture the DB related stuff in ERDs.
But how do you do something similar in VB and forms and queries?

Pointers, references, tips- anything helpful would be appreciated.
 
A

Albert D.Kallal

As to what you need to do often depends on who the target user is.

One of the first things you likely should do is split your database. This
splitting will allow you to continue development, or even produce updates to
the software when you are off site. Even if there is no need to work off
site, you should least compile the software from a mdb to a mde.

A mde means that the end users can't change the design. That mde also is
smaller, and loads faster. (source code is striped out etc). And, compiling
your project to mde don't make sense unless you split the database anyway
(you can't update a un-split mde code).

Given that you seem to understand development process, then splitting should
conceptually make sense to you. And, from a practical point of view, you
can't really develop an application unless it is split anyway. If you have
not split, then you REALLY need to read the following

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

Another good thing before you deploy is to setup the startup options. The
startup options are the final touches. With startup options, you can hide
all of the ms-access interface, and thus keep people out of the database
stuff (this will help people from hurting themselves). How much of the
interface you hide will much depend on your preferences. I tend to go all
the way, and given users a nice interface that requites no knowledge of how
to use ms-access (this reduces the pain of using the software by huge
amounts). So, have you considered custom menus for your users?

I have some nice screen shots of custom ms-access menus here, and explain
why you should consider using menus here:

http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm


If you want to see a quick small application that is "ready" for deployment
to users, then try downloading the 3rd example here:
http://www.members.shaw.ca/AlbertKallal/msaccess/DownLoad.htm
(the one that is 2000 merge, access interface hidden).
In my DB life, I capture the DB related stuff in ERDs.
Click to expand...

Yes, you should have a nicely laid out relationship window, and that is the
#1 thing I would look for.

9 out of 10 times, that relationship window is wrong, and things like left
joins etc. are NOT set correctly by the DEVELOPER in the db window.

If you look at the following screen shot, you can see that most relations
ships are this left join, and RI is enforced.

http://www.members.shaw.ca/AlbertKallal/Articles/PickSql/Appendex2.html

tblBgroup (booking group) for example may, or may not have payments made
(tblPayments). Thus, you can add a booking group, and NOT have to add child
payment records. However, full RI is enforced, and you can see the side ways
8
"omega" sign AND THE ARROW HEAD. If you go from the tblBgroup to the
its parent table, you will see table
tblBooking. You can easily see that there is a 1 to many here also, but NO
ARROW head exists. Thus, when I create a booking, my designs will ALWAYS
ASSUME that a child records in tblBgroup (booking group) will exist (ie: I
must code, and assume that when I add a tblBooking records, my code also
assumes that a tblBGroup will also have to be added). In plain English this
means that when I make a booking (reservation), my code assumes that
you MUST have people in that booking. However, I most certainly allow
people to be booked, but not yet have made any payments. So, your
relationship(s) if done right should reflect the rules you as a developer
want to maintain. The simple lookup fields are simply just a
arrow drawn, and no "1", or omega sign exists (tblPayments to tblHowpaid for
example is a simple lookup).

The ER diagram can convey a lot about your designs. Down the road, I can
now look at that diagram, and when writing code, I will know if the design
can, and does assume if child records are required.
But how do you do something similar in VB and forms and queries?
Click to expand...

You can print out the code, but I can't really say that helps much. There is
what we call the database documenter in ms-access.
This tool can printout all tables, and fields (in fact, in a nice columnar
lists if you select the options tab, and reduce some options). This tool
will also output all code, but I don't think that kind of huge printout is
really necessary. However, if you not played the with documenter in
ms-access, you should....

Another great tool here is mzw tools. This is a free add in for VB, and yes,
ms-access. It has a really nice source code "review" option, that will
show/highly any code that is un-used. And, the documentation printout is
nicer then the ms-access documenter (however, this utility is only for code,
so the decimator is much more extensive with other objects).

check out

www.mztools.com
 
C

Chaim

Thank you Albert for taking the time to respond so thoughtfully and
thoroughly. Very much appreciated.

As is usually the case, however, a little information leads to more
questions. I understood the concept of splitting the database into FE/BE.
Almost all of the books I've seen mention it, usually as a precursor to
delivery. But you seem to imply that this should be done early on. Do you do
it when you've got your table design in place, even while developing the
interface? It seems that the two pieces are actually independent (in the
sense that you can have interface and almost any data source behind that you
want). Is that perception accurate?

Your last response about printing out the code- that's not what I had in
mind. In the other half of my schizophrenic professional life, when I write
C++ (or whatever), there is a way of organizing your code into an
understandable structure that tells the observer something about the
structure of the code and how those parts interrelate (at least, if you do
it correctly, not something I'm sure I can lay claim to having done). There
are also CM and build tools that can interpret the structure. There are
documentation tools and there are design capture/code generation tools to
support the process (no comment on the quality or readability of the
generated code- that is off this topic). Are there similar tools available
in the MS Office and VB world? I just don't feel that VB is as amenable to
this sort of code structuring as some other languages. I have a similar
problem with Perl and Smalltalk code, but those are much smaller (and not
growing) pieces of my life, and so are not as critical for me. This is not
the case with the MS-related software.

As a last resort, if my customer is unwilling (or too cheap) to purchase
these tools (not uncommon, nor entirely unreasonable- after all, once I'm
done, their 'hired gun' is gone; what are they going to do with their
several thousand dollar investment in software tools?), in my UNIX./Linux
life, I ould get GNU software to fill (most) of those bills. Is there a
similar resource available in the Win/XP world?

Also, any thoughts about organizing code? The form modules obviously do that
for you, but what about organizing the code in a meaningful fashion in
'free' modules?

Once again, thanks for the time.
 
G

George Nicholson

There are also CM and build tools that can interpret the structure.

You might want to check out Access Analyzer (www.fmsinc.com). One of the
100+? reports it can generate is an "Application diagram" which provides, in
outline/tree form, a list of what procedures each db object calls, etc.

That, in addition to Object cross reference reports, etc., might be what you
are looking for.

HTH,
 
A

Albert D.Kallal

I understood the concept of splitting the database into FE/BE.
Almost all of the books I've seen mention it, usually as a precursor to
delivery. But you seem to imply that this should be done early on. Do you
do
it when you've got your table design in place, even while developing the
interface? It seems that the two pieces are actually independent (in the
sense that you can have interface and almost any data source behind that
you
want). Is that perception accurate?
Click to expand...

yes, the above is about right. As mentioned, you don't want to split too
soon, as it creates extra work. Usually around the time you are about to
start testing, or have the users start to play with the application is a
good
time to split.
Your last response about printing out the code- that's not what I had in
mind.
Click to expand...

Yes, I kind of figured the above. There are a number of tools that
map out the routines, but I never used one. The other poster
suggested that some tools from FMsinc might do this.

There are also other tools on the net that claim to do this for VBA
code, but I have not used them either....
Also, any thoughts about organizing code? The form modules obviously do
that
for you, but what about organizing the code in a meaningful fashion in
'free' modules?
Click to expand...

Nothing real new here. I do tend to group things in a fashion (a module for
menu code, a module for api's. A module for global report code etc).
 
Top