The fields are there, which you can see if you change the fill colour to something.
The issue is that it's showing the data for project name in the first record in the Weidner Msg Schedule table, which is empty.
What you've done with the Value1 field is create a relationship between the project table and the msg schedule table.
Each project must have a unique key, and all the messages that are related to the project must have the same key
I had someone else on the forum create that relationship... so while your comment makes sense, I'm not really sure how to fix it.
I'm sure it factors into this, each new project gets its own brand spanking new file make pro file.
I will basically be opening a master template and doing a save as for my first step.
That really misses the whole point of having a database.
Each Project should have a unique key, this is known as a primary key.
Every item in other tables that needs to relate back to information in the project table should have a foreign key that is the same as the primary key in the project table, as well as it's own unique primary key.
In your file every record in the Weidner Msg Schedule should have the key to the project it's related to in the field Weidner Msg Schedule::_Value One. For the project "Lets do this" this will be a "1", because the value in the field Project::Value one = 1
All your projects could be in one FileMaker file with unique values in the Primary Key for each project instead of Value one being the primary key, you could use Work Order another field.
I'd recommend :
renaming Project::Value one to Project::__PK_ProjectID (PK for primary key and the underscores so it stays at the top when sorted alphabetically) and change it to an auto-enter serial number rather than always being 1.
renaming Weidner Msg Schedule::_value one to Weidner Msg Schedule::_FK_ProjectID (FK for foreign key)
That was a little beyond my knowledge base, but I am sure it would make sense to someone with a little more FMP skill.
I ended up going back to the original file another user sent in to set up the original relationships, and started over. That managed to work -- I must have deleted / changed something important and not noticed.
While it took extra time, it ended up working. While it might not be a traditional use of having a database, the multiple files for each unique job makes sense for our current understanding and capacity. But, in the future we may look into the benefits.
The link for the post : (Almost) Same Footer in multiple layouts- auto update field