Re: I need some expert advice on database design

Thank you for taking the time to listen to me and for your feedback. I came
into this project 4-5 months after it started due to staff turnover. There
have been frequent meetings along the way to discuss our requirements,
workflow etc. My concerns aren't with design or concept issues. I expect
those type of issues. Like, he didn't really understand what we were saying
or we didn't understand what he was asking. Or when you actually test
something and see it, you find out it doesn't work exactly how you expected.
I expect that.

I also understand there are a variety of ways to accomplish the same task. I
also know getting a programmer to criticize another programmer may be like
getting a doctor to criticize another doctor. It is a touchy thing. Just
because a user didn't get what they wanted doesn't necessarily mean there was
a problem with the programmer. In this case I feel there are serious
problems with his programming skills. If I am wrong about this, please let
me know.

There are examples where it looks like he used the "I wonder what this does"
approach. The first two items in the code for the first form are:
Private Sub Command 31 Click()
End Sub
Private Sub Command 31 Enter()
End Sub

That's it. No actual code to go with it.

There is also code for a command button for a word application and one for
auto dialer. Both set up using the wizard. We have no use for either. And
none of these command buttons are actually on the form.

There is another form with 33 command buttons in the code. This particular
form only has two command buttons. Only one is controlled by code. The
other is controlled by a macro. It looks like this code was copied from
somewhere else since it references forms and queries that are not in our
database and we have no reason to use. Again, none of these command buttons
are even on the form. Looks like he broker a number of the commandments.

He actually had the following set up as a macro, but I converted it to code.
I have never used SendKeys and don't understand what they do. I never
bothered to learn about them since everyone says don't use them. What is he
trying to do here?

DoCmd.SetWarnings False
' % alt (t)ools (d)atabase utilities (c)ompact database
SendKeys "%tdc", False

Part of me thinks the reason it has been taking so long, is his lack of
skills. We do use alot of forms and collect alot of information, but other
than that, I don't think our requirements are that complicated. What we got
so far from him, should not have taken this long. Because of what I do know
about programming, I don't have any confidence about anything else he does,
especially things I don't know anything about.

Thank you. You have given me some good information. When I meet with
management I will suggest we look at the specs from this project. If I am
correct about his programming skills, I need to convince management that it
is a serious problem and not just me.

Larry Daugherty wrote:
From what you report, you may have just cause for concern...

Anyone who programs using Access's "Macros" as opposed to VBA is
highly suspect as a professional Access developer. Professional
Access Developers implement their designs using VBA to code just about
everything (depending on the version of Access there may be
justification for a few, very few, Macros). They use VBA from the
start. They don't program using Macros and then convert to VBA later.
Complex programs can develop mysterious bugs. VBA provides a rich
debugging environment. Macros are difficult and sometimes impossible
to debug.

From February to January is a calendar year. If there has been full
time development effort going on then you folks mush have some pretty
hefty requirements! That must cover several separable applications or
chunks of functionality. There must be some prototypes out and
running by now; at least for evaluation. Maybe replacing the
applications that went before.

Has anyone been working diligently with your developer in the role of
analyst to help her or him really understand the requirements and
workflows? What Specifications have been developed between the
developer and yourselves that you have both signed as essentially the
"contract" for the work being done? No matter how far along you think
you are in the project you need the specifications: Problem Statement,
Product Specification and Functional Specification. Those documents
are required to know that management, developer and all interested
parties really know the goal and when it has been achieved. They are
required before a Preliminary Design and Project Plan and Estimate can
be completed.

One absolute test of basic competence in developing with Access is
familiarity and proficiency in splitting the application into Front
End and Back End components and knowing several reasons why that is a
good thing to do. A competent developer can perform the actual
splitting (with or without the supplied tools) in under 5 minutes.
Make sure that you have copied the current application to a safe
backup area before you brace the developer with actually doing it. If
s/he is not familiar with the process the application could get
screwed up. Backup first! If you're concerned with demonstrating
misrepresentation or even fraud on the part of the developer then that
whole test might be carried out in the presence of yourself and one or
more senior managers in the office of a senior manager.

Another hallmark of a good developer is knowledge of Relational
theory. It is absolutely, positively impossible to produce good
schema without understanding the theory and practice of relational
design. The rule of thumb is to normalize one's data unless there is
a good reason not to do so on a case by case basis. Just so that
you'll have some understanding, visit

www.mvps.org/access and look for the "10 Commandments of
Relational Databases".

Keep an open mind. With one client I was asked to come on site and
overhaul and enhance all of their Access applications. There were
quite a few. With one exception, they were all enhanced and delivered
to rave reviews. That one balky project never did get totally
finished. The primary customer for that application was insecure and
balky and would not communicate. The parts of that project that were
defined by others were well done and quickly done. Her part never got
defined and never got done. The difference in the outcomes was
directly related to the difference in the quality of communication
with the analysts. None were "Analysts"; they were all users of the
applications in question.

Be aware that all is not lost regarding Macros and VBA. There is a
facility within Access to convert Macros to VBA. Again, back up your
complete application first. If the design was good then the
conversion should bring you along the desired direction. My concern
is that someone using Macros reflexively probably doesn't understand
the capabilities of Access.

Some other things:
Your superior knowledge of the desired outcomes may have given you
a huge leg up in producing your results.
You may have taken a different path to achieve the results you
did. You may be comparing apples and oranges.

Good luck with your application,

HTH
I work for a non-profit organization. With the help of a grant, we hired a
consultant to come in and design a database incorporating 3 divisions of our
[quoted text clipped - 24 lines]
Any suggestions/recommendations would be greatly appreciated.
Thanks.

http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/200712/1

--
Message posted via http://www.accessmonster.com

.