Hi,

I have been using Access at work quite a bit, and am now starting to create
my own database. I am wondering what the order of operations is regarding
"do I create the appearance of the form first" or do I need the information".
I dont have the info, as I am creating a recipe database, but I do have the
form setup with labels, boxes, but am wondering:

1) What is my first step?
2) How do I link it so that when I enter data, it gets created into a table
or tables, or query use later on?
3) Any good URL's to share? (something is wrong with my sound right now,
so a non-verbal website is most usable right now).


Thank you in advance!

On Sat, 4 Nov 2006 14:39:02 -0800, sm100378
<(E-Mail Removed)> wrote:

>Hi,
>
>I have been using Access at work quite a bit, and am now starting to create
>my own database. I am wondering what the order of operations is regarding
>"do I create the appearance of the form first" or do I need the information".
> I dont have the info, as I am creating a recipe database, but I do have the
>form setup with labels, boxes, but am wondering:
>
>1) What is my first step?

Lift your hands from the mouse and the keyboard, get up slowly, and
Step Away From The Computer.

Obtain a pad of paper and a pencil (a good eraser can be useful).

Identify the Entities - real-life persons, things, or events - of
importance to your application. Each type of Entity (for a recipe
database these might be Ingredients, Recipes, UnitsOfMeasure....)
you'll need a Table.

Identify each Entity's Attributes (discrete, atomic bits of
information that you need to know); each such attribute will be a
field in the table.

Identify the relationships bewteen the Entities represented by each
table - for example each Recipe will contain several ingredients, and
any Ingredient might be used in multiple recipes - so you have a many
to many relationship. Relationships will be one to one (VERY rare for
this level), one to many (universal), and many to many - which needs a
new table related one to many to each of the "one" sides.

>2) How do I link it so that when I enter data, it gets created into a table
>or tables, or query use later on?

The data is stored in Tables; linked, sorted, and arranged using
Queries. Forms are the preferred tool to enter data into the tables
(often via a Query).

Designing your forms first is a bit like building your frame and roof
before pouring the foundations... <g>

>3) Any good URL's to share? (something is wrong with my sound right now,
>so a non-verbal website is most usable right now).

Jeff Conrad's resources page:
http://home.bendbroadband.com/conrad...resources.html

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

particularly the tutorials under "Database Design 101" on Jeff's site.

John W. Vinson[MVP]

In addition to John's great advice, I also recommend Database Design
for Mere Mortals by Michael Hernandez.

In addition to the "pour the foundation before you build the frame and
roof" comment, I would add that you should create a blueprint before
you pour the foundation. A blueprint in the database world is the
list of features that your application will have, and a sketch (paper
and pencil is fine) of a database design that will support those
features.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com


On Sat, 04 Nov 2006 16:50:57 -0700, John Vinson
<jvinson@STOP_SPAM.WysardOfInfo.com> wrote:

>On Sat, 4 Nov 2006 14:39:02 -0800, sm100378
><(E-Mail Removed)> wrote:
>
>>Hi,
>>
>>I have been using Access at work quite a bit, and am now starting to create
>>my own database. I am wondering what the order of operations is regarding
>>"do I create the appearance of the form first" or do I need the information".
>> I dont have the info, as I am creating a recipe database, but I do have the
>>form setup with labels, boxes, but am wondering:
>>
>>1) What is my first step?
>
>Lift your hands from the mouse and the keyboard, get up slowly, and
>Step Away From The Computer.
>
>Obtain a pad of paper and a pencil (a good eraser can be useful).
>
>Identify the Entities - real-life persons, things, or events - of
>importance to your application. Each type of Entity (for a recipe
>database these might be Ingredients, Recipes, UnitsOfMeasure....)
>you'll need a Table.
>
>Identify each Entity's Attributes (discrete, atomic bits of
>information that you need to know); each such attribute will be a
>field in the table.
>
>Identify the relationships bewteen the Entities represented by each
>table - for example each Recipe will contain several ingredients, and
>any Ingredient might be used in multiple recipes - so you have a many
>to many relationship. Relationships will be one to one (VERY rare for
>this level), one to many (universal), and many to many - which needs a
>new table related one to many to each of the "one" sides.
>
>>2) How do I link it so that when I enter data, it gets created into a table
>>or tables, or query use later on?
>
>The data is stored in Tables; linked, sorted, and arranged using
>Queries. Forms are the preferred tool to enter data into the tables
>(often via a Query).
>
>Designing your forms first is a bit like building your frame and roof
>before pouring the foundations... <g>
>
>>3) Any good URL's to share? (something is wrong with my sound right now,
>>so a non-verbal website is most usable right now).
>
>Jeff Conrad's resources page:
>http://home.bendbroadband.com/conrad...resources.html
>
>The Access Web resources page:
>http://www.mvps.org/access/resources/index.html
>
>particularly the tutorials under "Database Design 101" on Jeff's site.
>
> John W. Vinson[MVP]

Thank you very much, great information from both.

"Armen Stein" wrote:

> In addition to John's great advice, I also recommend Database Design
> for Mere Mortals by Michael Hernandez.
>
> In addition to the "pour the foundation before you build the frame and
> roof" comment, I would add that you should create a blueprint before
> you pour the foundation. A blueprint in the database world is the
> list of features that your application will have, and a sketch (paper
> and pencil is fine) of a database design that will support those
> features.
>
> Armen Stein
> Microsoft Access MVP
> www.JStreetTech.com
>
>
> On Sat, 04 Nov 2006 16:50:57 -0700, John Vinson
> <jvinson@STOP_SPAM.WysardOfInfo.com> wrote:
>
> >On Sat, 4 Nov 2006 14:39:02 -0800, sm100378
> ><(E-Mail Removed)> wrote:
> >
> >>Hi,
> >>
> >>I have been using Access at work quite a bit, and am now starting to create
> >>my own database. I am wondering what the order of operations is regarding
> >>"do I create the appearance of the form first" or do I need the information".
> >> I dont have the info, as I am creating a recipe database, but I do have the
> >>form setup with labels, boxes, but am wondering:
> >>
> >>1) What is my first step?
> >
> >Lift your hands from the mouse and the keyboard, get up slowly, and
> >Step Away From The Computer.
> >
> >Obtain a pad of paper and a pencil (a good eraser can be useful).
> >
> >Identify the Entities - real-life persons, things, or events - of
> >importance to your application. Each type of Entity (for a recipe
> >database these might be Ingredients, Recipes, UnitsOfMeasure....)
> >you'll need a Table.
> >
> >Identify each Entity's Attributes (discrete, atomic bits of
> >information that you need to know); each such attribute will be a
> >field in the table.
> >
> >Identify the relationships bewteen the Entities represented by each
> >table - for example each Recipe will contain several ingredients, and
> >any Ingredient might be used in multiple recipes - so you have a many
> >to many relationship. Relationships will be one to one (VERY rare for
> >this level), one to many (universal), and many to many - which needs a
> >new table related one to many to each of the "one" sides.
> >
> >>2) How do I link it so that when I enter data, it gets created into a table
> >>or tables, or query use later on?
> >
> >The data is stored in Tables; linked, sorted, and arranged using
> >Queries. Forms are the preferred tool to enter data into the tables
> >(often via a Query).
> >
> >Designing your forms first is a bit like building your frame and roof
> >before pouring the foundations... <g>
> >
> >>3) Any good URL's to share? (something is wrong with my sound right now,
> >>so a non-verbal website is most usable right now).
> >
> >Jeff Conrad's resources page:
> >http://home.bendbroadband.com/conrad...resources.html
> >
> >The Access Web resources page:
> >http://www.mvps.org/access/resources/index.html
> >
> >particularly the tutorials under "Database Design 101" on Jeff's site.
> >
> > John W. Vinson[MVP]
>

Hi

Okay, I guess I am clueless on this question. I dont want to "customize"
the tables (i.e. datatype) until I have entered all my info or until I need
to address it, but how do I tell the form to create different tables or one
table with multipe colums that are appropriate for every input (category,
ingedients, name of recipe, etc)?


Thank you,

On Sun, 5 Nov 2006 16:03:01 -0800, sm100378
<(E-Mail Removed)> wrote:

>Hi
>
>Okay, I guess I am clueless on this question. I dont want to "customize"
>the tables (i.e. datatype) until I have entered all my info or until I need
>to address it, but how do I tell the form to create different tables or one
>table with multipe colums that are appropriate for every input (category,
>ingedients, name of recipe, etc)?
>
>
>Thank you,

WHOA!!!!

You're going about this BACKWARDS.

Create your tables (empty) first, with the appropriate datatypes. You
can't enter data into your tables until you have defined the tables!

Create the Tables, with the appropriate fields, datatypes, and
relationships. The tables are empty at this point.

THEN, after you have created the Tables, create Forms bound to those
tables. Use the Forms as tools to enter data into your tables. For
instance, you may have just a very small, simple maintenance form
frmCategories bound to the Categories table; you'ld enter your
information into that table using the form, and thereafter you'll only
need frmCategories when you want to add or change an existing
category, but you'll be able to use the Categories table as the
rowsource of a combo box on some other form (frmRecipes for example).

Forms don't "create" tables. Tables are the fundamental basis of the
application; Forms *use* tables, and are the servents of tables.

John W. Vinson[MVP]