It is technically possible to reach up into the parent control and have your way with the controls it contains, but it makes for code that's very difficult to maintain because if you change the structure of the parent control, you break code in all of the contained pages. That would be considered a very tightly-coupled design and it's often fragile.
A somehwat cleaner design would be to have your page classes raise an event when the Save button is pressed. Then your parent frame can sink the event and refresh whatever it knows needs to be refreshed after a save operation. That's easier to maintain because your components are more loosely coupled, but it still puts a lot of database knowledge into your GUI components. Such a design might be appropriate for a relatively simple app on which you don't expect to do a lot of maintenance or future enhancements.
The design pattern I prefer (as do many developers) is to isolate the database handling and business logic inside one or more classes with a simple programmatic interface that can be tested easily. The GUI components are kept as simple and thin as possible, so they can be easily changed if necessary. This is often called a Model-View-Controller pattern but there are other names for it. In your example, the "controller" class that encapsulates your business logic would have properties and methods for reading and setting information, and a "Save" or "Commit" method that writes changes to a database. Once the save is complete it would raise a "Saved" or "Changed" event that notifies all controls ("views") displaying information that the information has changed and they would refresh themselves based on the new values of the properties of your controller class.