Fairly New and Need Help (1 Viewer)

[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.