Forms are created once each. How many forms do you create from the same table? Not usually more than a couple. However, you write a lot more code and queries. If you are creating enough forms from a single table that you think that having a form level lookup saves you work, you should probably reconsider your entire design.
Ignore the warning as you wish. It comes from not just me but also from others who know quite a bit about Access.
I always love it when someone tells me that I need to change my design techniques. I am not sure to the level or degree that you have developed, but a lot of people developing in Access have not developed to the degree that I have in my career since 1991. I have also developed in DBase, Fox Pro, Paradox, Delphi, Quickbase, Salesforce, JD Edwards on Mainframe... Access will always be my go-to as long as the customer has an internal-facing audience. I can make Access look just like an EXE Application. The Users would not know the difference.
There is not a one-to-one for Table per Form. When a Table is structured to allow many Types, as in the case of this Entity Table, I use the Table to host all Vendors or Suppliers, Customers, Employees, etc. I certainly do not use the same Form each Entity type. I may have 5 Forms, maybe more, referencing this same Table depending on the requirement.
That said, when drop the Field onto the Form, the Lookup, i.e. Combo or List box, is automatically created.
So, I want you to perform a little experiment, and do not push yourself, but do so in your normal method of developing, time yourself as to how long it takes to create a combo or list box on a Screen referencing 4 Fields for the List, defining the Column Widths etc. Now multiply that * 5, assuming you would be adding it to 5 different screens. To me that is precious development time that could have been spent doing something else.
That is just one case as an example. I am not saying any of this to brag, because I certainly have other things to do. I have literally developed ERP Applications in Access that have over 2000 Forms and Reports, each. I can hear it now.... what application would ever need 2000 Forms! Can you imagine an ERP Application for manufacturing that can handle solids, liquids, food ingredients, weights, all the factoring, Automated Inventories, BOMs, AR, AP, Work Order Management, integrating 3rd party applications like AutoCad, MasterCam, Scales, etc.? A lot of those applications were created in Modules (not to be confused with VBA Modules) for distribution. The application also performs Financial Reporting, budgeting, trend analysis, etc. The BE had been scaled from an Access BE in its earlier days individually, to SQL Server to handle over 80 different manufacturing facilities collectively, and now resides on Azure SQL DB to the best of my knowledge. I have since retired, but to the best of my knowledge it is still in use today.
I have also developed Loan Origination and Servicing Applications in Access that connect to Banks for Merchant Services and Lockboxes. The only public facing web application is a payment portal and the ability to retrieve a variety of relevant reports. I was with the company for 8 years, where it began in a spreadsheet managing over 2,000 Loans on a portfolio of $23m to over 12,000 active loans on $190m and overall serviced over 70,000 loans for a niche market in property tax liens. I also wrote all their underwriting logic for analyzing over 25 million taxable properties in Texas just so they could market to the usual 100,000 on average delinquent properties. I retired from there in 2019.
These applications are very complex where a lookup or enumerator column can be referenced many times. For that reason, I have a method to my development madness to reduce the amount of development time. I do develop a lot smaller applications now in my sunset years, but I do not change my development techniques.
My apology for the dissertation. Have a great weekend!
