• create a new table occurrence for your master table, say, MasterList_byParcelNumber
• relate it to the Parcel table via the parcel number
• find all Parcel records where fk is empty (if you want to keep the existing fks – or Show all Records)
• use Replace Field Contents, calculated result with MasterList_byParcelNumber::pk
Now you can delete that utility table occurrence and use a “regular” relationship by Master::pk = Parcel::fk to display the Parcel “children” in a portal on the Master “parent” layout.
In the new table occurrence, what field should I be relating to the parcel table?
To be clear, I have my existing parcel table which has the parcel number, and a few other bits of information, but not the acreage; All parcels in this database currently have a fk. I just obtained another table which has all parcel numbers in the given county, more than I have in my database, with acreage information.
The portal was set up so every time I entered a new parcel via the portal, it was connected back to the master table via a fk in the parcels table to the primary key in the master table. I had it set so that when you entered a parcel number via the portal, it would check to make sure it was unique so that you wouldn't be creating parcels that belong to more than one property.
I am wondering now that with a complete "index" of parcels if it wouldnt just be easier to, upon entering a parcel via the way I have been doing it, to just look up the acreage from that "index".
I hope this is making sense, I have been trying to wrap my head around this for a while and my thoughts are getting a little scrambled!
I probably misread your fist post.
If you can match the parcel number in your existing table (parcels without acreage) against the new table (all parcels incl. acreage), then use this relationship
1. now (once) to update the existing records, using Replace Field Contents
2. in the future (continuously) to read in the acreage when you enter a new parcel, using an auto-enter calculation