Re: Help creating database

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



Larry

Nice summary!

I tend not to require the "explain everything you want before we start"
approach, though, because most folks don't know what they want!

I'll work with a prospective client to identify the 2 or 3 most-critical
aspects of what they're trying to accomplish, and negotiate an agreement to
work for a (limited) time on those. If those aren't possible, or achievable
within our lifetimes, then we're better off knowing that up front than
discovering that six months into the project.

After the first round, the client can walk away with what they have so far,
or engage in another round of identifying the (next) most critical aspects.

Of course, back to my original thought -- at each step, helping the client
identify what s/he's after has to come before any specs!

Regards

Jeff Boyce
Microsoft Office/Access MVP


"Larry Daugherty" <Larry.NoSpam.Daugherty@xxxxxxxxxxx> wrote in message
news:uzYYoelBKHA.1336@xxxxxxxxxxxxxxxxxxxxxxx
Hi Steve,

You're not hearing (or heeding) the good advice you have already
received. Believe it or not, we would like you to succeed with your
use of Access to solve your business problems. We will not knowingly
help you shoot yourself and your boss in the foot or feet. :-)

Your last post indicates that you haven't completed your analysis or
possibly don't know what it means or possibly think you know your
prospective application so well that you don't need to express it
before beginning your design. To wit: you have already proposed a
design based on incomplete and incorrect analysis. Proceeding in that
manner will lead to producing yet one more "laughable" application
that will be difficult and expensive to enhance and extend.

By the way, any application that finds some use has a value so don't
worry about past efforts. The problem with so many amateur Excel
based applications is that they are not highly automated and they are
not user friendly at all. They depend on the user being the most
critical part of the "program". The user is expected to know where to
go to replace data, enter new data and to interact in other ways with
what's there. Excel can be used to produce some pretty slick
professional applications (if I do say so myself!). The biggest
single problem people experience in coming to Access from managing
data in Excel is that they believe Access is simply a quirky version
of Excel. 'Taint so! Excel is flat. Access is Relational. Excel
is essentially a calculating platform. Access (en toto) is a
Relational Database Management System (RDBMS). Actually, Access is a
whole bunch of development tools that assume a RDBMS will be a part of
the mix.

In a "good" Access application you will not allow your users to see or
interact with the tables directly. You will provide meaningful forms
for your users to complete their tasks (in other words, all tasks have
to be defined and then you have to provide the forms and means to
complete them. No other tasks will be allowed!). To the extent
possible you analyze the proposed application and create a
specification before any code is written. When the specification is
complete, that becomes the "contract" for the application; all
epiphanies and bright ideas encountered before completion will be
noted for latter address. Deliver the contracted application and get
it signed off. If the will is there, peruse the new ideas with the
client for a new release. I would ask the client to use it and take
not of any more new ideas for inclusion in that second phase.

For a journeyman Access developer your proposed application seems to
be fairly small and relatively uncomplicated. If you and your boss
are ready, willing and able to fully specify the result you want and
the inputs available (with assistance from a developer) the technical
aspects of the whole thing could take a week or less. It could take
as long as a month if people are slow to respond with requested
documentation or to get to the phone. If you're in the least bit of a
hurry that's the way I'd recommend. Insist that the developer
document the code so that you can learn from how your Access
application was built.

Whether you do it yourself of have it done, you'll still want to learn
more about Access. There is a list of resources below that can help
you if you will use them and apply yourself. Start with the things
that seem easiest to learn and go on from there. If you were to
consume all of the items on the whole list you would be an Access guru
of awesome stature.

A couple of newsgroups I always recommend for Access newbies are:

microsoft.public.gettingstarted
microsoft.public.tablesdesign

A list of priceless Access resources I cribbed from the frequent posts
of John Vinson is below

Jeff Conrad's resources page:
http://www.accessmvp.com/JConrad/accessjunkie/resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

Roger Carlson's tutorials, samples and tips:
http://www.rogersaccesslibrary.com/

A free tutorial written by Crystal:
http://allenbrowne.com/casu-22.html

A video how-to series by Crystal:
http://www.YouTube.com/user/LearnAccessByCrystal

MVP Allen Browne's tutorials:
http://allenbrowne.com/links.html#Tutorials

HTH
--
-Larry-
--

"steve goodrich" <stevegoodrich@xxxxxxxxxxxxxx> wrote in message
news:VcqdnbquGb6n5sLXnZ2dnUVZ8vKdnZ2d@xxxxxxxxx
A new boss sounds a great idea! No he's ok really.

We work for a company that has a strict policy on the software that
can be
installed on our pcs. It's basically Access, Word, PowerPoint &
Excel -
That's it!
I have no programming experience and all the db's I have every built
have no
related tables. That said - they all work for us and have served us
for many
years with no problems. My job doesn't involve computers as such and
basically I have built the databases we use as a tool to do general
office
tasks. There are no external customers dependent on them. If the db
I build
goes wrong then it's no big deal, there's always another way to do
it. I am
trying to learn Access, but not coming from a technical background I
find it
very difficult - The help files for example might just as well be
written in
Chinese!!!

That said - I usually find a way of achieving what we need, (If one
of you
guys took a look in detail at one of our dbs you wouldn't stop
laughing for
a week!! (but they do what we want them to do, may not be efficient,
but
they get the job done).

Employing an Access developer to build the dbs is a non starter, I'm
sure
that it's not just our company out there that's trying to cut costs
at every
opportunity.

He's what I have in mind (Don't laugh)

A separate table for Daily tasks, weekly, monthly, quarterly,
yearly. with
the task required and a check box for each.

A form linked to each table so the user can check the relevant box
when the
task is complete.

A form (switchboard) with command buttons that will open each form

I could have a password protected form for the boss so he could
allocate
adhoc tasks,
Afew queries/Reports could be created as required.

The check boxes on the forms are just for staff to check when a task
has
been completed - the same as marking it off on a spreadsheet,
checking when
the box was checked or if it has been altered retrospectively is not
an
issue.

I am learning at a snails pace but am under no pressure to build an
all
singing all dancing db. Time is a real problem. as I say this is not
my full
time job, sort of trying to build it as and when I can to help
colleagues in
a great friendly office environment.

Any help from anyone would be greatly appreciated

Best regards

Steve Goodrich






"Jeff Boyce" <nonsense@xxxxxxxxxxxx> wrote in message
news:u307DHWBKHA.4336@xxxxxxxxxxxxxxxxxxxxxxx
... or find a new boss ... <g!>

Jeff

"Fred" <Fred@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:83AA2F6B-7A1E-4327-A397-DAB441C71E50@xxxxxxxxxxxxxxxx
We use Access as a platform for a combined planning and task
management
system. (Actually, all of the above integrate into a heirarchy
that goes
from strategic planning down to task levels.) It is highly
customized
to
us....which is why what we have would be worthless to you, but
illustrates
that the flexibility, power and openness of an Access platform
can
provide
advantages.

The gist of the excellent advice that the other respondents have
given
you
is that doing the described application (especially the special
things
that
your boss wants) yourself will probably be a sort of 1 year
learning
curve
(at a typical pace, if you're up for the learning effort) for
you,
combined
with developing the application over months and refining it over
years.
If
your boss doesn't want to hear that, then (as the respondents
described)
you're either going to have to get some help or use a completed
commercial
software....the latter would probably require some adaptations of
expectations.









.



Relevant Pages

  • Re: Help creating database
    ... help you shoot yourself and your boss in the foot or feet. ... The problem with so many amateur Excel ... For a journeyman Access developer your proposed application seems to ... A list of priceless Access resources I cribbed from the frequent posts ...
    (microsoft.public.access.gettingstarted)
  • Re: Cant connect to Analysis Server cube...
    ... I have recently created a new cube on a testing and development server using ... SQL2000 Developer Edition. ... Is it possible to connect to a OLAP cube from a client when the server is ... >> When trying to refresh the data in a excel pivot table based on an AS ...
    (microsoft.public.sqlserver.olap)
  • Re: Launching an .exe on intranet
    ... you mentioned that your client wanted to ... "replace the functionality of his Excel file... ... share access to it, an ASP app is what you want, in which case you only need ... VB is a language for writing executables. ...
    (microsoft.public.frontpage.programming)
  • Re: Consulting Rates
    ... Well, I suspect I may be a bit of an elitist, if by that you mean I think that a developer should deliver value for whatever rate they charge. ... I could continue to work and earn my hourly rate while he did the heavy lifting, so in the end, he saved me and the client money. ... For instance, if I can put in place a system that saves a client $500,000 per year in purchasing costs, then it's worth it to them to pay me $50,000, even if it takes me less than 100 hours of development to do so. ...
    (comp.databases.filemaker)
  • Re: Message-based vs. method-based interaction [was: Re: LSP and subtype]
    ... interface is always the method signature. ... We can name it for the owner context of what it does or we can name it for the client context, but we can't do both. ... overlaying some sort of developer structure on the 3GL syntax. ...
    (comp.object)