Verifying My DB Understanding - Implementing a paper form in Access (1 Viewer)

JMongi

Active member
Local time
Today, 05:00
Joined
Jan 6, 2021
Messages
802
My apologies if this is a basic question, but, I wanted to make sure that I had the correct understanding of how this would work. I have the data for our "Units" normalized. They have their own unique attributes and also subcomponents with their unique attributes. So there are a variety of tables with their relationships as you might expect.

So, we have a few different assessment forms that involve inspecting the units and all the sub-components and recording the attribute data on the form. I'd like to create an Access version of that form for these paper copies to be entered into. I presume that if I structure my query properly including the appropriate foreign keys that when this form is completed that Access will automatically generate the top level record (naturally) but also all of the "new" subcomponent records that are incorporated into the form.

Am I understanding this correctly?
 

theDBguy

I’m here to help
Staff member
Local time
Today, 02:00
Joined
Oct 29, 2018
Messages
21,467
Are you in the US Navy?

Just curious...
 

JMongi

Active member
Local time
Today, 05:00
Joined
Jan 6, 2021
Messages
802
LOL...no.
Too many comments about "subs"?
 

theDBguy

I’m here to help
Staff member
Local time
Today, 02:00
Joined
Oct 29, 2018
Messages
21,467
LOL...no.
Too many comments about "subs"?
No, I was going to say they have a program for something like that. But if you're not in the Navy, I am not sure how you can get a copy.
 

JMongi

Active member
Local time
Today, 05:00
Joined
Jan 6, 2021
Messages
802
My issue is that I wear too many hats. So it takes time for me to wrap my brain around DB development, and then once I do I'm whisked off to another task. Then I have to drag my brain back to DB development when I have time to work on this project.
 

JMongi

Active member
Local time
Today, 05:00
Joined
Jan 6, 2021
Messages
802
No, I was going to say they have a program for something like that. But if you're not in the Navy, I am not sure how you can get a copy.
So, is this implying that it is not as simple as I described?
 

NauticalGent

Ignore List Poster Boy
Local time
Today, 05:00
Joined
Apr 27, 2015
Messages
6,331
I presume that if I structure my query properly including the appropriate foreign keys that when this form is completed that Access will automatically generate the top level record (naturally) but also all of the "new" subcomponent records that are incorporated into the form.
Check out this video, i sounds like something you may be looking for...
 

JMongi

Active member
Local time
Today, 05:00
Joined
Jan 6, 2021
Messages
802
I feel like I've invoked an inside joke without knowing it...LOL!
 

theDBguy

I’m here to help
Staff member
Local time
Today, 02:00
Joined
Oct 29, 2018
Messages
21,467
So, is this implying that it is not as simple as I described?
No, it was implying you may not to reinvent the wheel (if you can get a copy of it).
 

JMongi

Active member
Local time
Today, 05:00
Joined
Jan 6, 2021
Messages
802
Well, I am a bit perplexed. It sounds like you are saying I need to do something special in order to accomplish those record creations, meaning Access won't do it automatically if I base my form on the appropriately structured query.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 04:00
Joined
Feb 28, 2001
Messages
27,172
Let's see if I can tackle some aspect of your question.

that when this form is completed that Access will automatically generate the top level record (naturally) but also all of the "new" subcomponent records that are incorporated into the form.
Can Access do this automatically? NO - as you asked the question. But YES - if you are willing to help it a bit by flexing in your expectations.

Your description sounds like you went through some work to normalize the tables. Even if they are not perfectly normalized, coming close is good as a starting place. Minimizes the dreaded "retrofit" that we inevitably encounter despite our best intentions. But here is the source of the "NO" in my answer: Access doesn't necessarily automatically create a parent form when you try to create the data existing entirely in sub-forms. If there is a true relationship (i.e. defined in the relationship window), you cannot create child records if the parent doesn't exist. The form/sub-form linkage can't be activated / realized / instantiated if the parent doesn't exist at the time you try to open the linked sub-forms. So you would never be able to fill in the child records - they can't exist.

Unless...

If your parent record includes a primary key that is either an autonumber OR the PK is a "natural" value derived from some attribute of the parent record's subject matter, AND you can manually enter that PK value, then you can link the new child records to the new vestigial parent record. The PK has to be a real, unique number or text field for this to work. If your unit IDs have the potential of duplicated numbers, then of course that ID field cannot be a PK, and Access will NOT allow you to establish a formal independent/dependent relationship with something else unless the independent side has a PK. IF you have an autonumber as a formality to uniquely identify the unit record, though, you can pre-define the unit "parent" record after which the child records can link in.

The problems will be in two main areas:

(a) timing - such that you create the parent well enough that linkages can be honored and then open the child records. So you might, on creating a new unit record, have to turn off the child sub-forms momentarily to prevent getting caught by the relational integrity trap. (When editing an exist record, this problem does not occur!)

(b) by necessity, the parent record that is created early in this process probably is not fully realized / filled in / whatever it is that it needs done. So before saving it all, you need to go back in fill in any parental blanks. Which means that either what you want comes from the sub-forms or you have these "other" potential parent fields displayed on the main form. Note also that there is an implied DEnormalization if everything you need for the fields of the parent record comes from data in the child records. Because in that case, you have duplicated data in the parent and its child record.

(c) the "Oops" factor - cause by defining a new record and then suddenly realized "Oh, darn, I can't do this yet." So you have to back out of it. If you don't issue your save commands, the child / sub records can still try to save themselves if you navigate or close the form. So you have to do some massive "UNDO" operations on each child record before navigating away from the record or closing the form. AND there is still that parent record you had to create when you were trying to make linkages for the child records. It also has to be removed since if you don't, you now have an incomplete, childless record floating around just waiting to trip up somebody's reports.

I should also add that you have asked a really good question because this aspect of form behavior is tied up with Relational Integrity principles (specifically, parent must exist before child), and RI issues are getting into advanced design topics. Therefore, good for you that you asked before you implemented. This would have been a hair-tearer really quick. My avatar image is really me, but before I lost all of my hair. So trust me, I know this topic (hair-tearing) intimately well.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 10:00
Joined
Feb 19, 2013
Messages
16,607
involve inspecting the units and all the sub-components and recording the attribute data on the form.
from this description you would have a parent form based on units and a subform for the sub components. If a sub component can be used in more than one unit then you have a many to many relationship and the subform would be based on the many to many table instead (and the subform for components would be located in the many to many form).

if you have created your relationships then access can do this for you, but the look and feel is at best basic and invariably you will want additional controls or even a parent form to the original parent form.

Note the form structure - each form is based on a single table (or a query with a single table as its source). Relationships are then managed automatically by the subform link child and link master properties

when this form is completed that Access will automatically generate the top level record (naturally) but also all of the "new" subcomponent records that are incorporated into the form.
This can be interpreted in a number of ways - the form should be bound which will automatically create the record. With regards the new subcomponents you will need to tell access what they would be for any given unit. This might be by a user selecting each component as required, or perhaps a 'template' table can be referenced or some other rule to do this for the user.
 

JMongi

Active member
Local time
Today, 05:00
Joined
Jan 6, 2021
Messages
802
@The_Doc_Man and @CJ_London - Thanks for the responses. That makes sense and also explains why this project isn't done yet!

I'm trying to figure out the best way to make use of a summer intern who is ready and willing to do a lot of the data gathering grunt work with a DB that's not ready to put data into. So I might need to be pragmatic and do a simple one table based on this form and give myself extra work to massage the collected data later when the DB application is finished.
 
Last edited:

CJ_London

Super Moderator
Staff member
Local time
Today, 10:00
Joined
Feb 19, 2013
Messages
16,607
Using access you can create the forms very quickly and should be fine for grunt data input. You can always refine the forms later on. This is on the proviso that your tables design is correct. Suggest you upload you relationship schema for us to comment on

the problem with the one table aka excel approach is it might take a long time to normalise the data due to typos, missing data and duplicates. Just doing that now for a client and there are a lot of inconsistencies which take time to resolve
 

Users who are viewing this thread

Top Bottom