Fairly New and Need Help (1 Viewer)

[Jack F]

So another example of a future feature that will be needed. Eventually your call list will get extremely large with old calls. That list will no longer be useable.
I can envision an option group at the top of the list to filter what you want to see.
Calls needing appointments
Calls with appointments
Open Callls (both of the above)
Closed Calls (ones with a service "call details")

The default is probably "open calls"

Also I did not add a place to put "Call Details", which if I understand is basically a record of service. When it started and when it completed. Also that table may need to get rethought. Currently a call comes in requesting service at a specific property. Then you schedule an appointment. You can schedule one or more appointments against that call. Which makes sense if the problem is not resolved. But if call details is the actual start and end times of the service (you would also need a actual date), the relationship is such that you could have multiple services against the same appointment. If that is not really the case and an appointment one service then those fields would go in the appointment table.
Apointmentdate
appointmentTime
ServiceDate
ServiceStartTime
ServiceEndTime.
If you make CallDetails a child table of an appointment but will never have more than one calldetail per appointment then that will create unneeded complexity. Instead of a couple more fields it is a whole new subform.

There is a possibility for multiple or return calls. Sometimes, an existing appointment can be used if the service is still related. However, if not, there would be a new service created.

 

[Isaac]

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

To make it even more nebulous, a lot of this depends on the platform you're using.

If you switch from Access to sql server, a lot of the naming convention 'needs' that Access seemed to present kind of disappear.
When I hold my mouse over something and it gives me 3 pages of information about that thing, the "tbl_" stuff then seems superfluous, and even, maybe 'bad'. Most companies I have worked for do not use stuff like tbl_ and qr_ and proc_ in a real data warehouse. But in Access it IS helpful because the IDE is so bad, so you end up having to overload the name of something with information about it...ironically, precisely what we avoid doing in table vs columns.

 

[Jack F]

To make it even more nebulous, a lot of this depends on the platform you're using.

If you switch from Access to sql server, a lot of the naming convention 'needs' that Access seemed to present kind of disappear.
When I hold my mouse over something and it gives me 3 pages of information about that thing, the "tbl_" stuff then seems superfluous, and even, maybe 'bad'. Most companies I have worked for do not use stuff like tbl_ and qr_ and proc_ in a real data warehouse. But in Access it IS helpful because the IDE is so bad, so you end up having to overload the name of something with information about it...ironically, precisely what we avoid doing in table vs columns.

I agree, I would have rather built it in a better software but, Access is what I have to work with here. It's a small business and cost is a factor. That is why I initially started the project the way I did. It would have been easier to code everything together in SQL without having to use the extra resources required in Access.

 

[MajP]

There is a possibility for multiple or return calls. Sometimes, an existing appointment can be used if the service is still related. However, if not, there would be a new service created.

So you need another subform to show the services for that appointment. If you want all of that on the dashboard you can shrink things down to make room an add the "Services" subform. The tricks is to show and hide that subform only for calls with assigned appointments. If not that form is visible but you cannot create a record in it because it needs to be linked to an appointment.

 

[MajP]

Added call details so all functionality should exist
1. Create customers
2. Create customer properties
3 log payment status (bad check, missed payment...)
2. create a call and assign a property / customer
3. assign an appointment to a call
4. add service information to an appointment