IF all the tabs show the same information then the fields shown here should be the fields that make up a single record in an Entrances table that you'd link to a Stores or Projects table like this:
Stores::__pkStoreID = Entrances::_fkStoreID
With this relationship a single portal could list all of your entrance data in a tabular format where each row is a different entrance. This would be easiest to use for data entry.
You could also modify the above relationship so that you only see one entrance at a time with the fields arrange similar to what you show in your tab control.
First, you'd add an entranceNumber field to your Entrances table--you'd probably also want that for the above example. Then, you can either modify the above relationship or use a second Tutorial: What are Table Occurrences? of Entrances to that shown above to get this relationship:
Stores::__pkStoreID = Entrances::_fkStoreID AND
Stores::SelectEntrance = Entrances::EntranceNumber
Then, you can make the portal a one row portal, extend the height of the portal row and position your fields much like you show them above. Then you can place SelectEntrance on that layout and by entering or selecting an Entrance number, see the data for one entrance at a time.
For an explanation of the notation that I am using, see the first post of: Common Forum Relationship and Field Notations Explained
Before I try your suggestion, let me show you how I have it currently. I have one table that has many attributes of a store, where we do have separate fields for each entrance. For example, entrance 1 type, entrance 1 level, then entrance 2 type, entrance 2 level, etc. And all these entrance fields are in my attribute table, not a separate entrance table. Currently, I have it linked to my store table so it shows the entrance fields for each store, based on the store number (ID). The image I'm providing I expanded showing that the entrance info is by store, but where I have the arrow pointing to is the portal I quickly created, where I want to show each entrance (1 thru 5), but within the portal, it gives all the information based on each entrance, which I tried to show on the side a couple of the fields that I would like to show in the portal, but the first image shows all the information that is being used/tracked for each entrance. Hope I'm making sense with what I have and what I'm trying to do.
I was afraid that this was the case and this is not how you should organize this data. You should set up a related table of entrances with one record for each entrance, not one set of fields in the same record for each entrance.
Please note that not only does this make the portal work, it's much more flexible. To add more entrances, you don't have to keep defining more fields-a data base design change requiring changes to the table and your layouts. Instead, you just add some more records in your portal--a simple data entry operation that does not require making any changes to the design of your database.