'Add Record' button on a form

[ramudo]

I am a novice on Access. I created a form that adds records to a table. I
included a button that adds the record to the table. When I click the 'Add
Record' button, the fields clear. Is there a way to have Access not clear
the fields so that I can reuse the data on some of the fields? Thank you for
your help.
Ramudo

 

[Jeff Boyce]

Ramudo

If your table structure is such that you could have multiple records in
which you would "reuse the data", your tables may need further
normalization. In a spreadsheet, you'd 'copy' data from one record to the
next. It is quite rare to need to do that in a well-normalized relational
database.

If you'll provide an example or two of the type of data you'd want to
"reuse", and a description of your current table structure, folks here may
be able to offer their experience/ideas.

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

 

[ramudo]

Thank you, Jeff Boyce, for making that clear to me. It is very apparent that
I have very little experience in Access. I am using a form to input invoice
data into a table. What I meant by reusing the data is that if when I
clicked the Add Record button, the customer code and customer name would
remain on the form so that I would not need to select them again, being that
I have multiple invoices for each customer. All other fields would clear.
Thank you again for your help.

 

[Jeff Boyce]

As BruceM has pointed out, there's a very good chance that your table
structure more closely resembles a spreadsheet than a relational database
table.

Access is optimized for well-normalized data.

In your situation, it sounds like you have [Customers] and
[CustomerInvoices]. Without a better understanding of your specific
situation, and knowing only those two, your table structure could be (and
would help make better use of Access by being) something like:

tblCustomer
CustomerID
FName
LName
CustomerCode
... (other customer-specific info)

trelCustomerInvoice
CustomerInvoiceID
CustomerID (this is considered a "foreign key", pointing back to the
record of the customer who "owns" this invoice)
InvoiceDate
... (other invoice-specific info)

Note that this assumes you can have zero, one, or many invoices per
customer.

If you'll post more detailed description of what you're working on, folks
here may be able to offer more specific suggestions.

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

 

[ramudo]

Thank you Jeff Boyce.

Ramudo

If your table structure is such that you could have multiple records in
which you would "reuse the data", your tables may need further
normalization. In a spreadsheet, you'd 'copy' data from one record to the
next. It is quite rare to need to do that in a well-normalized relational
database.

If you'll provide an example or two of the type of data you'd want to
"reuse", and a description of your current table structure, folks here may
be able to offer their experience/ideas.

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.




.

 

[ramudo]

Thank you Jeff Boyce

As BruceM has pointed out, there's a very good chance that your table
structure more closely resembles a spreadsheet than a relational database
table.

Access is optimized for well-normalized data.

In your situation, it sounds like you have [Customers] and
[CustomerInvoices]. Without a better understanding of your specific
situation, and knowing only those two, your table structure could be (and
would help make better use of Access by being) something like:

tblCustomer
CustomerID
FName
LName
CustomerCode
... (other customer-specific info)

trelCustomerInvoice
CustomerInvoiceID
CustomerID (this is considered a "foreign key", pointing back to the
record of the customer who "owns" this invoice)
InvoiceDate
... (other invoice-specific info)

Note that this assumes you can have zero, one, or many invoices per
customer.

If you'll post more detailed description of what you're working on, folks
here may be able to offer more specific suggestions.

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

Thank you, Jeff Boyce, for making that clear to me. It is very apparent
that
I have very little experience in Access. I am using a form to input
invoice
data into a table. What I meant by reusing the data is that if when I
clicked the Add Record button, the customer code and customer name would
remain on the form so that I would not need to select them again, being
that
I have multiple invoices for each customer. All other fields would clear.
Thank you again for your help.

.

 

[ramudo]

Thank you BruceM.

You would need at least a Customer table, an Invoice table, and an
InvoiceDetails table (for invoice line items). Each Customer may have many
invoices, so there is a one-to-many relationship between the Customers and
Invoices tables. Likewise, each Invoice may have many InvoiceDetails, so
there is a one-to-many relationship between the Invoices and InvoiceDetails
tables.

The short answer is that what you seek can be done, but you will not be
helping yourself to proceed as you describe. It may sort of work at first,
but there are many places where it can cause major future problems. Also, it
will require a certain amount of coding to implement it, which has its own
learning curve.

This is more than can be talked through in a newsgroup (at least it is for me)
, but if you have some basic terminology and techniques under your belt you
can make progress, and come back with a specific question. To that end it
will probably help to review some tutorials, etc. about Access and realtional
databases in general. Here are some links that may help. Crystal's tutorial
is as good a place as any to get started, IMHO.

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

Thank you, Jeff Boyce, for making that clear to me. It is very apparent that
I have very little experience in Access. I am using a form to input invoice
data into a table. What I meant by reusing the data is that if when I
clicked the Add Record button, the customer code and customer name would
remain on the form so that I would not need to select them again, being that
I have multiple invoices for each customer. All other fields would clear.
Thank you again for your help.

Ramudo

[quoted text clipped - 23 lines]

.

--
Message posted via AccessMonster.com


.