I was going through your database example again today and liked the way it used a "virtual table" and mirrored the form to the table. My only concern with this was that when I did have to make changes (which are infrequent as you have guessed), I have to make changes to the table plus the form to make sure they match. This would add an extra table for each of the document types (even if it is just table which is used temporarily). I have coded it today without binding just to make sure the proof of concept works
In the first example where I used the subform, the point was that this would not require code, table, or form redesign in order to add or change records. But as you pointed out it is not as customizeable. If document types have a different set of issues then I would add in the issue table a field for document type. My guess is that you may actually need a many to many table if issues are shared across document types. You definitely would not need multiple tables for each document type. Now if it was me and I was going to try to maintain this, I would probably make code to help build the forms. It would add the correct amount of checks, name them correctly, tag them correctly, temporarily place them, and provide the correct labels. Then I just have to clean up the size of the labels, and do some movement for aesthetics .
You would build your different forms using a query but would have a single table. The unbound form design suffers from the above problems. Whatever way you go the main point is that you are better off with a normalized table structure and with some code and trickery you can usually come up with a non normalized presentation that is more user friendly.
As per your other question, I will stir up some controversy, but read this first
https://docs.microsoft.com/en-us/ar...en-are-you-required-to-set-objects-to-nothing
IMO (based on facts) regardless of what you read or heard there is almost no reason to ever set an object variable to nothing. People on this forum and others say all them time that you have to, but if asked they can not explain why or their answers are just wrong. There are a few times when you should, but it is never the case that people site. The referenced post explains those rare times. People will say that it is just good coding practice. If writing unnecessary code without understanding of what it does is good practice then I guess, sure. So the logic is in the .1% chance you will need it, it is better to do it every time just in case. Personally, I prefer to understand the .1%. In all of my coding I know of a handful of cases where I had to set an object variable to nothing and these were all in composite custom classes or automation of other applications.
The author describes it as Cargo Cult Programming
When I see code like this, the first thing I think is cargo cult programmer. Someone was told that the magic invocation that keeps the alligators away is to put a banana in your ear and then set objects to Nothing when you're done with them. They do, and hey, it works! No alligators!
As for closing a recordset, there are more times you should as compared to setting an object to nothing. If working with an external datasource I will close the connection. But closing a local access recordset is also mostly unnecessary. I have left thousands of thousands of recordsets open and have let code execution take care of it without the world ending.
My other guess is that many people are too lazy to learn the rare cases where you would need to close a recordset and set an object to nothing. So the easier solution is to tell everyone you have to do it all the time. If it makes you more comfortable then have at it, just understand about 99.9% of the time it does nothing.