Learn how to test your application.

Changing database structures always require testing. A lot is going on when you make alterations in your datamodel, and these alterations will eventually influence the code that the AllpicationBuilder produces.
It is not the syntax that you have to worry about; if there was an error in the syntax the code cound not have been produced in the first place at all.
It is the logic that can cause the errors and, subsequenly, the problems of sorting out and fixing.

You have changed two modules: The Officers table has got two new fieldnames, and the Activities table has got a changed fieldname.
You have removed the existing modules; code and tables, and re-installed the updated ones. And you have re-filled the tables with the content from the XData tabs.

Now it's time to see if the change in your datamodel produces the expected result.
The first check is viewing the tablecontent right after filling it with the ExcelReader. All data should be in the tablerecords, and the records must show individually when you click the "Select" or "Edit" button.
In this case the real change is in the Officers table. There should show a dropdown list that enables you to select an activity that has to be linked to this officer when editing this record.

Select an officer for editing and observe the Activities dropdown
list. Click on an activity; this will be the officer's one.
Click "Update" to store the record.
Click on a "Select" button to see the Modal Popup.

Clicking either on the blue text "Rafting" in the view or on the button "YCActivities". This will force the popup to show.

Leave the popup first by clicking the "Cancel" button in the popup, than the "Cancel" button on the view.

You're done with this lesson.

---->> Lesson 13: A new table; The ActivityPlan