RidgeStar
About
Locations
Manual
Preface
Introduction
Versions
Concepts
Construction
Usage
Operations
Questions
Features
Accounting
Anchor
Audit
BulkLoad
BulkMail
Conflicts
Directory
Finances
Fragments
iCalendar
KeySearch
Locations
Mail
MessageHelp
Method
Multiple
Options
PageText
PasswordReset
Passwords
Photos
SelfAssign
Shortcuts
Reminder
Responsive
SSL
Topics
Turnback
UID
WSYSARMA
Settings
Internals
Appendices
Reference
Service
Logon
RidgeStar

Manual: Features-Anchor

Logontranslate
Get Started |Calendar |Locations
What is the Anchor Concept?
An Anchor is a single database field within a single table that may contain a Value that establishes other dependent data field Values in the same data record. It is, essentially, a "Key Field" that influences other permissable data field values contained within the same data record.
Why use the Concept?
When implemented, it improves the quality and referential integrity of individual database records. As an example, it can help insure that the Level, Division, etc. values associated with a specific League are, indeed, properly associated with the League (where the League would be the Anchor field)
How is the concept implemented?
The SiteManager defines which database tables contain Anchor fields (marked by the presence of a Anchor symbol) within a single RidgeStar Site and which specific data field will act as the Anchor. Additional Settings can be configured to identify valid Values for the dependent data fields (based upon the Anchor value in effect at that moment in time). Thus, all definition activity occurs as one or more Settings that are administered via Administrator: Options-Settings.

The following discussion is, by its nature, quite generalized in scope. You will need to establish a communication with your RidgeStar Account Representative with any questions you may have about implementation within your site (if Feature=Anchor is installed in your site).

Defining default Database Field Values

For the majority of database field values, the SiteManager can define valid Values through Administrator: Options-Settings. For the purposes of this example, we'll use the Referees.biz Matches table Level field definitions. Thus, establishing the default Field Values for the Level field, the SiteManager might define a Setting=Level that would appear as follows:

Figure 1

  1. We've defined 18 different possibilities for the data field named Level within the database.

Of course, when the Site delivers a FORM for detail data input, it will offer all these alternatives (as appropriate). However, what if we only wanted 4 of these for one League, 2 of them for another League, and so on?

Define Anchor Field identities

The SiteManager identifies the "Key field" (the Anchor field) by establishing a Setting=Anchor entry with Administrator: Options-Settings that declares by database Table which data field will act as the Anchor.

Figure 2

  1. The definition identifies a single Database table (named "Matches") has a data field named "dmaLeague" that should be treated as the Anchor when processing the Matches table.
  2. The Notes are always simply comments, but (in this case) reminds the SiteManager of the syntax to be used within the Value (separate Table=>Anchor specifications with a simple comma, when needed).

Establish related Data Field values (by Anchor Value)

Once the Anchor is defined for a database table, the SiteManager can establish an additional Setting containing the valid Values for a data field when the Anchor Value takes on a specific value.

Figure 3

Notice that entry #3 in this example is the summary listing for the preceding figure, which is the overall system default for the field named "Level". However, there are also additional Settings named in the general form {Anchor}.Level that indicate the acceptable Values for Level when a specific Anchor value is present. In this example, for League=NFHS Matches, we only accept JV or Varsity as valid Level values.

Visual Presentation of the Anchor and Related Data Fields

When a detail form for an Anchor eligible database table is presented, it will identify the Anchor field by placing the Anchor in front of the Anchor field. Those related or dependent fields contained within the same form will also have a small symbol representing the Anchor value placed in front of them (as portrayed below).

Figure 4

  1. The detail FORM display for a Match contains the Anchor to mark which of the data fields in the form is the Anchor field
  2. When one of the related data fields has an Anchor constrained pulldown, it's marked with a small symbol associated with the Anchor value. In this case, the ICWSL indicates the data field is ICWSL specific (controlled by the Anchor value)
  3. For the data fields that have no Anchor constraint and you are viewing the complete list of Site Default values, there is no indicator or symbol present. In this example, neither the Division or Season pulldowns are constrained or controlled by the League=ICWSL Setting.

What happens when the Anchor Field value changes?

When the Visitor to a page clicks "Update", the Site will compare the values sent from the Desktop to the Server against the then current combination of Anchor to dependent field values. Errors or inconsistencies are noted and the Update is only applied to the database if all values are in a proper combination.

Figure 5

  1. Both the Authority and Level values from the prior League=ICWSL pulldowns are invalid and are rejected when the Visitor changed the Anchor field value from ICWSL to NFHS. The requested Update is NOT completed and the database continues to contain the data values as of the last successful update.
  2. The FORM is redisplayed with the dependent pulldown values consisting of defined values for the new Anchor value (in the example, NFHS).

Frequently Asked Questions

Are there any limits as to which database table the Anchor mechanism can be used with?
No, not architecturally (meaning, from a design or implementation standpoint). There are certainly logical inconsistencies that shouldn't be done (e.g. making a Status field the Anchor, that sort of thing).
Can a single Database Table have 2 or more Anchor fields?
No, each database table can only contain a single Anchor field.
How do I define which data fields are "dependent" on the Anchor field?
Simply define a Setting with a Name in the general format {Anchor-Value}.{Field-Name}. When you have the definitions setup correctly, you will see a small Symbol appear right before the dependent data field.

It IS quite common for your RidgeStar representative to have to be involved to set up and/or select a small symbol to represent all Values that may appear in your Anchor field. When an Anchor value you have chosen has no corresponding symbol, the symbol will appear as the Unknown Symbol error. Contact your RidgeStar Account Representative and identify the missing Anchor symbol.

Is a dependent field restricted to pulldown type fields only?
No, but for all practical purposes, you should assume (from a User Interface standpoint) that it is.
Does the Anchor mechanism check or validate the values provided in Bulk Load?
Yes. When Feature=Anchor is active, Bulk Load will validate all input field values against existing Setting definitions, taking the Anchor field value into account.