The active document may contain text segments that correspond to particular fields in particular database objects. For example, the active document may contain a segment corresponding to the Behavior field in learning objective 1234. Indeed, the document may contain all the content fields for numerous objectives. These content fields in the document might be newer, improved versions of their counterparts in the database. Rather than hunt and peck your way through the database, manually updating each field one by one, you can use the Update Database tool to transfer the newer, improved fields from the document into the database—in one stroke.
Why Would a Field be Newer?
Why might the fields in the document be newer, improved versions of their database counterparts? Well, consider this workflow process:
1.A document is generated in VISION, by running a report. The document includes the contents of various fields from various VISION data objects, for instance, the objective content fields for all objectives in a particular lesson. If some or all of those fields are presently empty, the document shows placeholders indicating where the content from those fields would appear. The document is saved to an RTF file.
2.Next, this RTF document is handed off to somebody, perhaps an instructor or subject-matter expert (SME), who edits the document. That editing can be done outside VISION in a program like MS Word. The instructor or SME revises or fills in the data fields in the document and saves the changes to the original RTF file.
3.Finally, the revised RTF document is reopened in VISION. The fields in the document now are newer, improved versions of the database fields that they originated from. The object now is to update those original database fields with the newer content from the document. Because the document fields are marked (by means of hidden text identifiers), the Update Database tool knows which data fields they correspond to, and can update those fields.
Advantages
In this way, training content can be developed outside VISION, through a document-style interface. Two advantages arise from this:
1.The author does not need to know how to use VISION, or even have access to it.
2.The authoring can be done in a text editor superior to VISION's internal text editor, such as Microsoft Word. Among other things, this permits the convenience of using macros in developing content.
Field Participation
Which fields in the document participate in the update (or highlight) action?
That is controlled by several settings:
•First, the participation is limited to the chosen document portion.
•Within the chosen portion, participation is further limited to fields of the type specified by the checkbox selections.
•If the Only <<X>> 
checkbox is checked, then participation is limited still further to just those fields that are marked, i.e., those fields in which the field "anchors" are visible. See Marked Fields Only.
Marking Specific Fields
You might choose to select specific kinds of nodes or a specific section of the document to highlight or update.
Why would some fields be marked, but not others?
By default, the field "anchors" — << and >> — are not visible in a VISION-generated document. However, the active document may have been generated by a VISION report that is expressly designed for the purpose of updating the database. Such a report may have exposed the normally hidden field anchors for some fields, while leaving them hidden everywhere else.
The report has exposed the markers in order to identify and draw attention to those fields that the user is encouraged to fill in or improve. By checking the Only <<x>> checkbox, the update (and highlight) operation is limited to just those marked fields. The update will skip non-marked fields.
Why restrict the update to marked fields only?
A VISION-generated document may include many fields from the database, of which only some have likely been improved by the document user, after the document generation. Excluding unmarked fields improves the efficiency of the update by ignoring fields in the document that do correspond to actual data fields, but that the document user probably hasn't changed.
Efficiency, however, is not the only purpose: preventing errors is another. Imagine a report that shows the same field more than once. Consider the following document excerpt, for example:
3.1. Enumerate steps for starting the machine
In this example, notice that the objective behavior statement ("Enumerate steps ...") is shown twice for the same objective. If the document user changes the first instance of the behavior and then proceeds to update the database, the change will not be made. Why? Because after updating the database with the revised first instance, the update then proceeds to update the same field again—with the second instance, which has not changed. Because it is associated with the same data field, the second update overwrites the first.
Notice, however, that in this excerpt, the second instance of the behavior is marked, but not the first. This is an aid to the document user, to prevent just that kind of overwrite mistake that could occur. If the document user is careful to update only the marked fields, and if the update is done with the Only <<x>> checkbox checked, then mistakes of this kind are unlikely to occur.
