Search results

Looks good. Thanks.

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

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.

Those make it a bit easier and more intuitive.

:p:p:p

Nice, thanks for sharing

No, that is handled by a different person in the company. I come into play once the parts are here and ready to schedule.

I have the information in accounting software. I do not necessarily need to duplicate it in the dispatch part. I do have a status field in the appointment setting information that designates complete, on hold, go back, etc...

The address can be fundamentally different. If you were a company and manage multiple properties, I would create a designation for each. However for billing, I would have a separate address for that. However, if you had a local office and a separate billing address, I can designate the local...

That is sometimes the case.

Thank you for your help and information.

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.

That is somewhat how I wound up seeking help. It was getting beyond my knowledge which meant my basic design concept was becoming more faulty.

I am thinking subforms as well, if not trying expanded datasheet. I am pulling information from 5 different tables. The goal is to reduce that to veiw in one place, such as a pop-up or modul. This example is closer to achieving that.

I agree, take a call and make an appointment if there are no restrictions. The forms and subforms may be beyond my knowledge right now. I am working on trying to learn how to build nested subforms. So, that way, I should in theory be able to put all the information in 1 place and in front of me...

Thanks for the input. I see what you are saying. I like the designation _FK. I used a check box set up for PO_NO_Required. Hopefully it will make it easier in a form.

Thank you for pointing this out. It makes sense in the bigger picture. I will do some adjusting as I continue developing the database.

Thank you. I will adjust the names. I agree, in the future as the data grows, it will get confusing.

Thanks and I see your point. A 1 to many does clean up the model much better than my idea. Yes, a customer can have multiple COD's. They may have multiple commercial address or be a private real esate investor, being required to pay cash at the time of service. Perhaps, they do not have a credit...

Yes