Fairly New and Need Help (5 Viewers)

[Jack F]

@Jack F - Actually, one little nit-pick. It is exactly wrong to define a naming convention, start to use it, and then abandon it even though you didn't abandon the project. Inconsistency in naming when you COULD have done something to avoid it is wrong - and YOU will be the one who suffers later when you have to do maintenance on a badly entangled set of code with names that don't follow the rules.

MajP is absolutely right, though. As far as naming conventions are concerned, you get to choose because it is your project, and in that context, there is no good or bad. If you are comfortable with it and can stick with the convention, it is by definition good - at least for you.

Thank you. As I continue the development, I will work on better naming. So far, this is all concept and design stage. I agree, the future of the project as is, will definitely be a mess during maintenance as the data grows.

 

[LarryE]

If you are going to use forms and sub-forms (which I prefer) then the design will give you a logical sequence by which you learn which form is a subform of which parent form. I have taken MajP's design and rearranged it so all of the primary keys are on the left and foreign keys on the right, so the design is read from left to right:

So, when you design your forms, you would work backwards from right to left.

1. Create a continuous form for tblCallDetails input first
2. Create a single form for tblAppointments input. Then add the tblCallDetails form as a subform.
3. Create a single form for the tblCalls input. Then add the tblAppointments form as a subform.
4. Create a single form for the tblProperties input. Then add the tblCalls form as a subform.
5. Finally create a single form for the tblCustomers input. Then add the tblProperties form as a subform.

When you open your project, you just autoopen the tblCustomers form only. All the others are already there and linked with Master/Child foreign key fields. If you link forms this way, ACCESS will automatically add the correct foreign keys when new records are created on any of the forms and keep track of everything else with fewer problems. I always use as much native ACCESS functionality as possible.

I prefer this method over using menus especially when users need all information in front of them.

 

[Jack F]

If you are going to use forms and sub-forms (which I prefer) then the design will give you a logical sequence by which you learn which form is a subform of which parent form. I have taken MajP's design and rearranged it so all of the primary keys are on the left and foreign keys on the right, so the design is read from left to right:
View attachment 123078
So, when you design your forms, you would work backwards from right to left.

1. Create a continuous form for tblCallDetails input first
2. Create a single form for tblAppointments input. Then add the tblCallDetails form as a subform.
3. Create a single form for the tblCalls input. Then add the tblAppointments form as a subform.
4. Create a single form for the tblProperties input. Then add the tblCalls form as a subform.
5. Finally create a single form for the tblCustomers input. Then add the tblProperties form as a subform.

When you open your project, you just autoopen the tblCustomers form only. All the others are already there and linked with Master/Child foreign key fields. If you link forms this way, ACCESS will automatically add the correct foreign keys when new records are created on any of the forms and keep track of everything else with fewer problems. I always use as much native ACCESS functionality as possible.

I prefer this method over using menus especially when users need all information in front of them.

Thank you for your help and information.

 

[MajP]

In your business does the customer have multiple properties as well as a main property?
The way this is set up it would be like the customer is McDonalds and in the customer table you have a corporate address information for billing but you are going out and servicing individual McDonald properties.
If that is not the case then you may not need the address information in the customer table. Or even if that is the fact then you still remove that information here and add the corporate as another property. Then add a field to mark the property as something like "Billing", "Service" to differenitate.