# Revision history [back]

Hello,

Started to look at your sample & relate it to your question. It appears you have two major problems.

First is you lack of understanding of Base Forms. Now please bear with the terms (not my doing). The Forms section on the main Base screen allows opening a "Form". This Base Form actually contains internal "Form(s)", sub forms, sub sub forms etc. It can have MULTIPLE internal "Forms" each having sub forms, sub sub forms etc. Now each of these forms, sub form sub sub forms etc. can be associated with a TABLE. So the bottom line is how these are all set up and possibly linked for proper association.

The next problem is your design. Without going too deep into looking at your structure, it appears you have not separated out data into proper tables. For example, MainT really should be a Customer table with only customer info. Other information such as payments, procedures, billing amounts etc. should be in related tables. This keeps data organized and accessible in a variety of ways. No need for at least some of these queries you have (again only a brief look).

Unfortunately, if you do not address this now it is probable you will only add to more complicated answers in the future.

To give you a minuscule idea of the forms part, I had started to re-do the PaymentEntryForm when seeing the potential problems. The small revision is the PaymentEntryFormModified. Instead of using a query with parameters, the main form is a List Box for last names & Date control for Service Date. These are tied to a Filter table which is used for MainT table display.

Sample ---- FormTableProblems.odb

Note: There are MANY ways to enhance the selection process for this form.

Hello,

Started to look at your sample & relate it to your question. It appears you have two major problems.

First is you lack of understanding of Base Forms. Now please bear with the terms (not my doing). The Forms section on the main Base screen allows opening a "Form". This Base Form actually contains internal "Form(s)", sub forms, sub sub forms etc. It can have MULTIPLE internal "Forms" each having sub forms, sub sub forms etc. Now each of these forms, sub form sub sub forms etc. can be associated with a TABLE. So the bottom line is how these are all set up and possibly linked for proper association.

The next problem is your design. Without going too deep into looking at your structure, it appears you have not separated out data into proper tables. For example, MainT really should be a Customer table with only customer info. Other information such as payments, procedures, billing amounts etc. should be in related tables. This keeps data organized and accessible in a variety of ways. No need for at least some of these queries you have (again only a brief look).

Unfortunately, if you do not address this now it is probable you will only add to more complicated answers in the future.

To give you a minuscule idea of the forms part, I had started to re-do the PaymentEntryForm when seeing the potential problems. The small revision is the PaymentEntryFormModified. Instead of using a query with parameters, the main form is a List Box for last names & Date control for Service Date. These are tied to a Filter table which is used for MainT table display.

Sample ---- FormTableProblems.odb

Note: There are MANY ways to enhance the selection process for this form.

Edit:

You mentioned replacing query with list boxes but that is not true. What was done was to use table filtering in conjunction with the list box/date control. See -> Filter/Search with Forms (leveraging SubForms). I have posted many samples in this forum using table filtering.

LO documentation is located here -> Documentation/Publications. You will find Base documents, samples & toward the bottom some how-to's.

SQL is a must for working with databases. It can easily help avoid the need for using macros. The are many sites on the net to help with this. Here is one -> w3schools.com.

There is a great deal more but don't want to overwhelm you. This should get you in the right direction.