Help creating database

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" wrote in message
...
... or find a new boss ... g!

Jeff

"Fred" wrote in message
...
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.

Steve

I'll refer you back to one of my earlier responses.

I urge you to consider the 3-4 learning curves I mentioned. If you feel
like you're near the bottom on any of those, plan on taking the time to
learn your way up that/those curves before expecting to get Access to work
well/easily for you.

There's no harm, no foul in creating something that works. Now you just
need to decide whether the goodies Access offers is worth the pain to come
up to speed. If you have another way to get the job done, one that you
already understand, go for it!

That said, Access is more a power tool than a bookcase. You can learn to
use it safely and properly, and, in the end, build some really nifty
bookcases. Just don't expect to walk up to it and have it be easy to
understand.

Best of luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP


"steve goodrich" wrote in message
...
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" wrote in message
...
... or find a new boss ... g!

Jeff

"Fred" wrote in message
...
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.

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 a

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/acc...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" wrote in message
...
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" wrote in message
...
... or find a new boss ... g!

Jeff

"Fred" wrote in message
...
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.

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" wrote in message
...
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 a

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/acc...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" wrote in message
...
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" wrote in message
...
... or find a new boss ... g!

Jeff

"Fred" wrote in message
...
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.

Here's some baby step advice on top of the excellent big picture advice
already given to you byu others.

With regard to your likely level of Access knowledgein the near future, the
more complex user-access cotrol functionality etc. that your boss is
discussing makes it that your question is mixing two things together.

It sort of like saying "my boss is thinking of switching me from a
motorcycle to a car, and, by the way, the reason for the switch is to win
the Indy 500 with the car next week. Do you think I can handle this
switch to a car?

My advice is that a good start would be to tell your boss that under the
multiplle constraints he has given you (you have to build it 100% DIY - no
pre-made software, and no paid help) that the only choice he has is to
seperate the "car switch" from the Indy 500.

In other words, to start by just moving your application to Access, (which
probablyu won't be that tough) and winning the Indy 500 will have to wait
under the constraints that have been placed on you.

Thanks guys for all your advice. I know it's a very big learning curve - I'm
learning all the time. I find this ng one of the most useful resources -
keep up the good work, it really is appreciated.

"Fred" wrote in message
...
Here's some baby step advice on top of the excellent big picture advice
already given to you byu others.

With regard to your likely level of Access knowledgein the near future,
the
more complex user-access cotrol functionality etc. that your boss is
discussing makes it that your question is mixing two things together.

It sort of like saying "my boss is thinking of switching me from a
motorcycle to a car, and, by the way, the reason for the switch is to win
the Indy 500 with the car next week. Do you think I can handle this
switch to a car?

My advice is that a good start would be to tell your boss that under the
multiplle constraints he has given you (you have to build it 100% DIY - no
pre-made software, and no paid help) that the only choice he has is to
seperate the "car switch" from the Indy 500.

In other words, to start by just moving your application to Access, (which
probablyu won't be that tough) and winning the Indy 500 will have to wait
under the constraints that have been placed on you.

Thanks Jeff,

I hope it was useful to OP.

Most useful to the neophyte is getting to know about the territory
that he or she doesn't yet know but that they will likely have to
travel in order to get done what they want.

I admire the ambition of everyone who is learning and using Access.
Having learned all of the little I know about the subject by self
directed efforts, I'm in complete empathy. Help files, books,
magazines and other resources all helped. How about Smart Access!! I
also learned a lot by lurking these Access newsgroups to see what
others were posting and seeing if I could understand and resolve their
issues. That was time consuming but useful. Eventually, I started
occasionally responding to posts. When I do respond I usually do so
with an awareness of the hundreds of "lurkers" who aren't a visible
part of the dialogue but who benefit nonetheless. Sometimes I don't
give posters the simple result that they seek but point them instead
to the resources they have available to be able to help themselves.

I'm awed by the succinct responses of John Vinson and Allen Browne in
particular. I don't think they're naturals, I think they worked to
get that way. There are lots of others ...

Your own posts are great examples of common sense reasoning applied to
a complex subject area. Getting people to understand the real issues
they face in getting to a solution they want is even more important
than complete mastery of the technical expertise. You help lots of
people grasp that valuable insight and place Access in its proper
place as a tool for providing solutions rather than as the embodiment
of specific solutions.

Kudos

--
-Larry-
--

"Jeff Boyce" wrote in message
...
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" wrote in
message
...
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 a

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/acc...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" wrote in message
...
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" wrote in message
...
... or find a new boss ... g!

Jeff

"Fred" wrote in message
...
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.

Thank you for the kind words, Larry. I, too, am in awe of John & Allen,
among many others.

I decided long ago that my mind doesn't go the same places that theirs do,
and I don't even aspire to be able to do what they do.

I also realized long ago that I 'break things'. Not maliciously, but just
because I tend to ask those sometimes annoying questions that can help
reveal what isn't yet understood.

Some folks just want to know "what button to push" ... and there are many
here who can help them.

I tend to ask "why are you pushing that button?" ... or even "?there's a
button?!"

Regards

Jeff

"Larry Daugherty" wrote in message
...
Thanks Jeff,

I hope it was useful to OP.

Most useful to the neophyte is getting to know about the territory
that he or she doesn't yet know but that they will likely have to
travel in order to get done what they want.

I admire the ambition of everyone who is learning and using Access.
Having learned all of the little I know about the subject by self
directed efforts, I'm in complete empathy. Help files, books,
magazines and other resources all helped. How about Smart Access!! I
also learned a lot by lurking these Access newsgroups to see what
others were posting and seeing if I could understand and resolve their
issues. That was time consuming but useful. Eventually, I started
occasionally responding to posts. When I do respond I usually do so
with an awareness of the hundreds of "lurkers" who aren't a visible
part of the dialogue but who benefit nonetheless. Sometimes I don't
give posters the simple result that they seek but point them instead
to the resources they have available to be able to help themselves.

I'm awed by the succinct responses of John Vinson and Allen Browne in
particular. I don't think they're naturals, I think they worked to
get that way. There are lots of others ...

Your own posts are great examples of common sense reasoning applied to
a complex subject area. Getting people to understand the real issues
they face in getting to a solution they want is even more important
than complete mastery of the technical expertise. You help lots of
people grasp that valuable insight and place Access in its proper
place as a tool for providing solutions rather than as the embodiment
of specific solutions.

Kudos

--
-Larry-
--

"Jeff Boyce" wrote in message
...
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" wrote in
message
...
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 a

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/acc...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" wrote in message
...
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" wrote in message
...
... or find a new boss ... g!

Jeff

"Fred" wrote in message
...
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.