How can I add a row from a form?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I'm struggling with a couple of concepts here and would really appreciate
any help :)

1. I've tried to make an update query for my database. I'm making an
installation log (customers and their installation date) and would like to
make a form to easily add jobs. The problem is that I cannot find a way to
just get some boxes representing the values I'm looking for, then validating
them, and then inserting them into my database.

2. Ultimately, I want #1 to just be a form presented, the consultant inserts
the details, click a button of some sort, and the data is inserted into the
db.

Anyone?
 
Lars said:
Hi,

I'm struggling with a couple of concepts here and would really appreciate
any help :)

1. I've tried to make an update query for my database. I'm making an
installation log (customers and their installation date) and would like to
make a form to easily add jobs. The problem is that I cannot find a way to
just get some boxes representing the values I'm looking for, then
validating
them, and then inserting them into my database.

2. Ultimately, I want #1 to just be a form presented, the consultant
inserts
the details, click a button of some sort, and the data is inserted into
the
db.

Base a select query on your table, then base a form on that query. You
don't need an update query.

HTH - Keith.
www.keithwilby.com
 
Hmmm...I'm not sure I follow you.

Off the top of my head a select would be something like:
SELECT name, surname, somethingelse
FROM customers;

How would that help me put something into the db? I don't want the whole
list and then append from the bottom, just the fields and then putting the
fields into the db.

Cheers!
 
How would that help me put something into the db? I don't want the whole
list and then append from the bottom, just the fields and then putting the
fields into the db.

What's the structure of your table? How are the people in the People
table related to the jobs in the Job table? Does each Job involve many
people? Does each person work on only one job, or might they work on
several?

You will NOT want to store name, surname, etc. redundantly in any
other table. That information should be stored only in the single
People table.

John W. Vinson[MVP]
 
There are different tables:
Jobs: Which customer gets which product, and which consultant is doing it
Customers: Name, address, etc of each customer
Consultants: Name and contact info for each one
Products: simple list of products

In jobs, anything (?) can appear several times
In Customers: company name can appear several times, but surname+name can
only appear once
In consultants: surname+name can only appear once

So...it's really quite simple. The form is only for adding new people in the
Customers table, but I will use the same principle for consultants and jobs.

Cheers!
 
There are different tables:
Jobs: Which customer gets which product, and which consultant is doing it

What constitutes a "job"?
Customers: Name, address, etc of each customer

You MUST have a unique ID as the primary key of this table.
Consultants: Name and contact info for each one

Likewise. If the two tables have the same structure, consider using
just one People table with a yes/no field Cousultant to identify which
people are consultants.
Products: simple list of products

Does each job involve one and only one product? or might it involve
several?
In jobs, anything (?) can appear several times
In Customers: company name can appear several times, but surname+name can
only appear once

I have three friends here in Parma: Fred Brown; his son Fred Brown;
and an unrelated gentleman named Fred Brown.

Name & surname are NOT unique and are not suitable as a unique
identifier.
In consultants: surname+name can only appear once

So...it's really quite simple. The form is only for adding new people in the
Customers table, but I will use the same principle for consultants and jobs.

You need at least two additional tables. Since (apparently, though you
don't say) each Job can involve several Customers, and each Customer
can be involved with multiple Jobs, you have a many-to-many
relationship, which needs a "resolver" table with the unique JobID (if
your Jobs table doesn't have one... create one!); similarly for
Consultants. If a Job will NEVER have more than one customer or one
consultant your structure above may be OK.

Assuming that the latter is true, you can use a continuous Form with a
combo box for the customer ID and the consultantID. Since I don't know
how jobs relate to products, I can't advise on that issue, but I
suspect you need a JobProducts table linked to both.


John W. Vinson[MVP]
 
Back
Top