Follow these steps:
There are no choices in the bottom panel of the Add Statement dialog. This is because the Toolset has already made the choice for us. Looking at the statement we are trying to build in the upper panel, we can see that it has already selected the golfer for us to read. As mentioned before, the Toolset tries to assist us by automating some tasks and selections. In this particular case, we only had one entity action view defined. Entity action views are the only views that can be read, updated, created, or deleted. Since we were trying to add a read statement, the tool knows we want to use an entity action view, and since we only had one entity action view defined, it selected it for us. If we had two or more entity action views, it would have waited for us to select one.
As such, the Add push button is enabled. If we wanted to, we can add the statement as is. And we would read some golfer, but the golfer we read would not likely be the golfer we wanted to update, unless we only had one golfer in the database. Therefore, in virtually every case, when performing a read, you will want to qualify the read, to get a particular occurrence of the thing being read.
As mentioned before, the Toolset tries to assist you in making your selections. So when qualifying the read statement, the Toolset will present you with what essentially amounts to a series of filters. There are many ways to construct a read statement; providing only an all-inclusive listing of choices would be daunting. However, if you select the wrong filter up front, you likely will not see what you are looking for, as you get further down constructing the statement. Therefore, if you have decided you have taken the wrong path, you can simply select the Undo push button to back up one or more choices.
In the vast majority of cases, you will qualify the thing being read either by an attribute of itself, or by its relationship to something else. In addition, if you qualify it by its relationship to something else, then you generally need to qualify the something else with an attribute of it.
For example, in this particular case, we want to read the golfer by an attribute of the golfer. We want to read the golfer whose (attribute) user ID is equal to the user ID passed to us in the import golfer user ID. Another example of an attribute qualification would be if we wanted to read all of the golfers whose (attribute) last name is equal to the last name provided to us in the import golfer last name field.
An example of a relationship qualifier would be if we wanted to read all of the scoring records for a golfer. We do not want to read the golfer, only the golfer's scoring records. So we would read each of the scoring records, where the desired scoring records (relationship) were maintained by some golfer, [and then we would use an attribute qualifier to qualify which particular golfer] and that golfer (attribute) user ID is equal to the import golfer user ID.
Therefore, the next step is to qualify the golfer being read.
READ golfer
scoring record
WHERE …
If this had been the case, then after selecting DESIRED persistent view, the Toolset would have shown us both golfer and scoring record (since we desire them both), and then asked us to select the one which we want to qualify first. However, since we only had one entity action view in our read list, it selected it for us. Since (from number step four) we specified attribute (qualifier) view, it is now asking us to select the attribute of golfer that we want to use as the qualifier. Select userid.
The completed UPDATE GOLFER action diagram should look as follows. Remember that the order of the attribute views within the entity views is not important.
Save your model and close the UPDATE GOLFER action diagram.
Copyright © 2013 CA.
All rights reserved.
|
|