Steven Monai
Creation Date: December 20, 2001
Revision Dates: November 27, 2002; December 27, 2002; January 8, 2003;
September 3, 2003; December 14, 2003
© 2001 – 2003 Northern Interior Vegetation Management Association
Introduction
You have just received a set of error reports generated by the TRENDS database. Don’t panic. This document is intended to help you interpret the errors and decide how to fix them. Don’t be surprised or disappointed if the answer to your specific question does not appear explicitly in this document, as it is meant to be a quick-and-dirty “how to” rather than an exhaustive, detailed description of all possible errors. If you still need help after reading this document, feel free to contact the TRENDS database steward or the
TRENDS protocol steward (email addresses and phone numbers are available at the
NIVMA website (http://www.nivma.bc.ca).
There are two stages of error checking that occur on any given file. The first stage is the called the range/code/not-null checking stage. The second stage is called the logical checking stage.
Stage 1 of error checking: Range/Code/Not-Null Error checks
The range/code/not-null stage ensures, as much as possible, that all fields that require a value are filled-in with an appropriate value. Numerical fields have their values checked, to ensure they fall within a corresponding range of valid values. Code fields are checked to ensure the values they contain appear in a corresponding list of valid codes. All fields are checked to ensure that a value is filled-in when necessary. If there are errors, the database generates two text files that (tersely) describe the errors (where nnn is the dataentry reference number):
1.
errorlog_ nnn .txt
--- This file lists the error messages, grouped into sections by table name.
2.
errorrecs_ nnn .txt
--- This file lists the erroneous database records themselves, again grouped into sections by table name. The records are listed in a comma-delimited format appropriate to the record’s table. The TRENDS table formats are listed in the database documentation.
The errorlog file has a particular format that appears something like the following example:
Report created 13:36:33 Jan 8, 2002
==============================================================================
Page 1 of 11

Error report for data reference 395 (395)
==============================================================================
BEGIN Table TRND_CA Error Report ---------------------------------------------
Record 1: Rejected - Error on table TRND_CA.
check constraint (NN_TRND_CA_ANNUINC) violated
Table TRND_CA:
408 Rows successfully loaded.
1 Row not loaded due to data errors.
END Table TRND_CA Error Report
In the example, there is one erroneous CA record. (Ignore the “ TRND_ ” prefix. CA records store the annual increment measurements for repeatedly measured trees. There is a list of TRENDS database table names and what they mean in Appendix A.) The error message is saying something very technical that need not be fully understood to understand how to fix the error. The name of the error check that failed, given in parentheses (in this case, “ NN_TRND_CA_ANNUINC ”), gives us all the information we need. The prefix “ NN ” tells us that the error is a “not-null” error. The suffix “ ANNUINC ” tells us that the database field named ANNUINC is erroneous. (The TRENDS database documentation describes the fields of every table.) The following table lists the three possible error name prefixes:
Prefix Meaning
NN
Not-null error. Errors of this type indicate that the indicated field is either null
(empty) when it shouldn’t be, or there is a value in that field when there shouldn’t be.
CD
Code error. The indicated field contains a code that does not appear in the field’s list of valid codes.
RG
Range error. The indicated field contains a numerical value that is outside the range of valid values for that field.
Returning to the example given above, the error message is telling us that there is a notnull error on table CA in field ANNUINC . But we still don’t know which particular record is erroneous; the error message only mentions “ Record 1 ”. That’s where the errorrecs file comes in.
The errorrecs file contains the actual database records corresponding to the error messages in the errorlog file. The records in the errorrecs file appear in exactly the same order as they are mentioned in the errorlog file. The following example of an errorrecs file corresponds to the previous example errorlog file:
Reference number 395 (395) report created 13:36:33 Jan 8, 2002
--------------------------------------------------------------------------------
Rejected CA records:
1 395,1230,CA,FJ3506,506,4,1,2001,R673,2001,
--------------------------------------------------------------------------------
Page 2 of 11

The single CA record, numbered 1 , corresponds to “ Record 1 ” mentioned in the errorlog file. The complete documentation of the TRENDS table formats appears elsewhere, but most tables have commonalities that we can exploit, so that it’s almost never necessary to go to the documentation. The first three fields are always the same.
The first field is the reference number (e.g. 395 ), which will be constant for all records a given file. The second field is an internal sequence number (e.g. 1230 ), which is unimportant for our purposes here. The third field is the table name of the record (e.g.
CA ), which is constant for all records of a given table. The next four fields are the obligation number fields of the TRENDS installation, in the following order: Timbermark
(e.g. FJ3506 ), Cutting Permit (e.g. 506 ), Block (e.g. 4 ), and Installation number (e.g.
1 ). The remaining fields vary depending on the table. Very often, the next three fields are the year, month, and day of measurement. Rarely, as in our example, the given table doesn’t store the complete date (yr/mon/day), but only the year of measurement (e.g.
2001 ). The remaining fields always vary, depending on the table. In our example, the field following the year of measurement is clearly a tree number, since the value there is
“ R673 ”, a typical tree number.
So, we’ve seen how the errorlog and errorrecs reports combine to give an indication of what the error conditions are, and which records are affected. This information is then used to guide error corrections. The error condition itself usually gives a strong indication of the remedial action to take. For example, a not-null error typically means that a necessary value was omitted and needs to be filled-in. However, the obvious fix is not always the correct action to take, so some care and thought must always be exercised.
Stage 2 of Error Checking: Logical Error checks
The logical error checks check various error conditions at a conceptually higher level of abstraction than the stage 1 checks. Stage 2 checks concern themselves mainly with relationships between records in a single table, and also between different tables. The output of stage 2 is two files, which are analogous to the two files created by stage 1:
1.
errors_ nnn .txt
--- This file lists the logical errors.
2.
errorrecs_logical_ nnn .txt
--- This file lists the records corresponding to the error messages listed in errors_ nnn .txt
.
The errors file looks much like the following example:
Reference number 402 (402) report created 11:59:23 Dec 20, 2001
--------------------------------------------------------------------------------
402, C3, 142 -- Tree SPECIES does not match SPECIES in associated Art. Regen. History.
402, C3, 194 -- Tree SPECIES does not match SPECIES in associated Art. Regen. History.
402, C4, 395 -- This tree measurement has no matching current year leader measurement in table CA.
In this example, there are three logical errors, one error per line. Each error line gives the reference number of the file (e.g. 402), the table name of the affected record (e.g. C3), the internal record sequence number (e.g. 142), and finally the error message itself. The combination of the table name and the internal sequence number is used to match the
Page 3 of 11

error message with the corresponding data record in the errorrecs_logical file, of which the following is an example:
Reference number 402 (402) report created 11:59:51 Dec 20, 2001
--------------------------------------------------------------------------------
Problem C3 records:
142,C3,ANC,1998,1059,1,2001,8,7,1,10,R017,Pli,Y,PS,-7,,g,H
194,C3,ANC,1998,1059,1,2001,8,7,3,32,R069,Sb,Y,PS,0,,g,H
--------------------------------------------------------------------------------
Problem C4 records:
395,C4,ANC,1997,1027,1,2001,7,31,R053,39,27,6,,14,S,3,CR,,NL,,X,,BS,,,,,
There are three error records listed in this example, corresponding with the three error messages listed in the errors file. There is always a one-to-one correspondence between an error message in one file and an error record in the other file. If a particular record has more than one logical error listed, then that record will appear the same number of times in the errorrecs_logical file.
A brief note about the differences between Stage 1 and Stage 2 error reports:
There are two significant differences between how records are listed in errorrecs_logical and how they’re listed in errorrecs (the stage 1 error records file). The differences are:
1.
In errorrecs , the records are numbered to match the way the errorlog report refers to them; in errorrecs_logical , the records are not numbered, since the errors file refers to them by their table name and internal sequence number.
2.
In errorrecs_logical , the records are listed with their reference number field omitted, while in errorrecs , the reference number is not omitted.
These differences arose as a result of the way the error checking system evolved, and unfortunately, are a potential cause of confusion. This issue will hopefully be addressed in the future.
Descriptions of specific Range/Code/Not-Null Errors
For the most part, the range/code/not-null error codes are straightforward. However, some codes either don’t exactly follow the naming conventions given above, or they represent an error condition that doesn’t neatly fall into one of the three main categories.
The following are some of these codes:
RG_TRND_H1_BAD_CALC_HEIGHT , RG_TRND_I1_BAD_CALC_HEIGHT ,
RG_TRND_M1_BAD_CALC_HEIGHT : One of these codes appear when the given height of a tree (either a Height Correction (H1), a Site Index (I1), or a Multi-story Heights &
Ages (M1) tree) does not match the height as calculated from its top %, bottom %, slope distance, and height correction values. You likely have a typo in one of those values, or you miscalculated the height from those values.
Page 4 of 11

NN_TRND_C4_DMG1_VIGOUR_2 : This code appears when an RMT yearlymeasurement record (C4) indicates that a tree has a vigour of 2, and yet there is no damage code entered for it. Whenever a tree is given a vigour of 2, there must be at least one damage code entered to indicate why the tree is in distress. You should either enter the missing damage code(s), or fix the vigour code.
Descriptions of specific Logical Errors
The following logical error messages may appear in your error reports. Note that this list is by no means exhaustive, but the most common messages encountered to date have been included. I've tried to explain what each one means, and to give some possible reasons why the error condition exists (to give you some idea about how to fix the error):
"Tree SPECIES does not match SPECIES in associated Art. Regen. History." – (Affects
C3 records) This means exactly what it says. There are several ways that this error could have come about. There could be an incorrect species code in either the RMT record or the Artificial Regen. record. Or, the tree might be linked to the wrong Artificial Regen. record.
"This tree measurement has no matching current year leader measurement in table CA." –
(Affects C4 records) The checking program has determined that the RMT measurement should have a corresponding Annual Increment that is a current-year-leader, but none was found. (Refer to the Templates User Guide for a detailed description of when an
RMT must have a current-year-leader measurement, and when it must not). Perhaps a wrong date was entered in the Annual Increments subform, or perhaps no increment information was entered at all.
"This tree measurement has a current year leader (in table CA), yet the tree is 1+0 summer planted stock, measured the same year it was planted." – (Affects C4 records)
This means that the RMT measurement has a corresponding current-year-leader measurement in the Annual Increments subform, but it should not, for the reason given.
(Refer to the Templates User Guide for a detailed description of when an RMT must have a current-year-leader measurement, and when it must not). Perhaps the tree is linked to the wrong Artificial Regen. record, or perhaps the leader was measured when it shouldn't have been.
"This tree measurement has no matching current year leader measurement in table CA." –
(Affects C4 records) The RMT measurement should have a corresponding current-yearleader measurement in the Annual Increments subform, but none was found. Perhaps a wrong date was entered in the Annual Increments subform, or perhaps the leader measurement was not entered, or perhaps the leader was not measured at all. (Refer to the
Templates User Guide for a detailed description of when an RMT must have a currentyear-leader measurement, and when it must not).
“This tree measurement has a current year leader (in table CA), yet its HT is at least 200 cm.” – (Affects C4 records) The RMT measurement indicates that the tree’s height is
Page 5 of 11

now at least 200 cm, which means that the tree must not have a current-year-leader measurement this year. It is possible that either the tree’s height is incorrect (and its correct value is below 200 cm), or the current-year-leader measurement should be deleted from the Annual Increments subform. (Refer to the Templates User Guide for a detailed description of when an RMT must have a current-year-leader measurement, and when it must not).
“This tree measurement has a current year leader (in table CA), yet its VIGOUR is 0 or
1.” – (Affects C4 records) The given RMT measurement indicates that the tree is missing or dead (0 or 1, respectively), yet a corresponding current-year leader measurement for that tree was entered. You should either fix the tree measurement’s VIGOUR code to a live value (2 or 3), or you should delete the current-year leader increment record.
"The field RMT_CD = Y, yet there are no corresponding Competition Description records in table p2." – (Affects C4 records) The RMT measurement must have a corresponding Competition Description (CD), but none was found. The CD might not have been entered, or maybe it was entered under the wrong year.
“No matching cb record(s) exist.” – (Affects C3 records) The RMT has no link to its BC
Stocking Standards. (Every RMT in BC must be linked to a least one Stocking Standard.)
To fix this error, link the RMT to its Stocking Standards reference number(s).
“No matching cc record(s) exist.” – (Affects C3 records) The RMT has no link to its
Alberta Survey Standards. (Every RMT in Alberta must be linked to at least one Survey
Standard.) To fix this error, link the RMT to its Survey Standards reference number(s).
“No matching c5 record(s) exist.” – (Affects C3 records) The RMT has no link to its
Harvest/Disturbance history. Every RMT must have Harvest/Disturbance history. To fix this error, link the RMT to its corresponding Harvest Reference Number(s)
“No matching c6 record(s) exist.” – (Affects C3 records) The RMT has no link to its Site
Prep History. Every RMT must have Site Prep history. To fix this error, link the RMT to its corresponding Site Prep reference number(s).
“VIGOUR = 1, yet there are 1 corresponding Competition Description record(s) in table p2.” – (Affects C4 records) The RMT is dead, and dead trees should not have a
Competition Description entered for them in the year that they’re observed to be dead.
Perhaps the competition was assessed for a dead tree (in which case, just delete the competition description), or perhaps the VIGOUR code entered in the tree measurement is wrong.
“This tree was assessed as dead (VIGOUR = 1) in a previous year.” – (Affects C4 records) The RMT was determined to be dead in a previous year, which means that it should not have been assessed this year. Once a tree is dead, it should no longer be measured. If the tree was incorrectly judged to be dead in a previous year, and none of its measurements were recorded at that time, then that assessment must be corrected:
Page 6 of 11

Change the tree’s previous years’ vigour from 1 to 0, so that instead of being dead, the tree was just “missing”. If the tree was really dead in a previous year, then this year’s assessment should be deleted.
“This tree is missing or dead (VIGOUR = 0 or 1), yet it has no live assessments
(VIGOUR = 2 or 3) in past years.” – (Affects C4 records) The RMT measurement indicates that the tree is either missing or dead, yet the database has no live record of the tree prior to the given year of measurement. This is an error because a tree must be alive
(and not missing!) at least once: when it is first picked-up for measurement. You either picked-up a dead (or, somehow, a missing) tree for measurement this year (which you shouldn’t have done), or you have a typo in the vigour code.
“No matching c4 record(s) exist.” – (Affects CA records) The given RMT Annual
Increment record was given a measurement year that doesn’t match the measurement year in any of the RMT’s yearly measurement records. It is possible that no RMT measurement record was entered in the Remaining Measurements subform, in which case, you should enter it. Or, you may have entered an incorrect measurement year in either the Annual Increments subform or the Remaining Measurements subform. Since the templates don’t allow you to change a measurement year after it’s been entered and saved, to fix an incorrect measurement year you will have to delete the entire record affected and then completely re-enter it with the corrected year. Note that if you delete a record in the Remaining Measurements subform, the corresponding year’s Competition
Description for that tree is also deleted, so if you delete an RMT measurement record be prepared to re-enter its Competition Description.
“1 matching i1 record(s) exist.” – (Affects H1 records) This means that the given Height
Correction (H1) record has a corresponding Site Index tree (I1) record. When a Site
Index record exists for a tree, no Height Correction record for that same tree is allowed to exist, because the Height Correction record is redundant (since the Site Index tree record should already contain an accurate tree height measurement). Most times, you can just delete the redundant H1 record.
“1 matching h1 record(s) exist.” – (Affects I1 records) This means that the given Site
Index tree has a corresponding Height Correction (H1) record. When a Site Index record exists for a tree, no Height Correction record for that same tree is allowed to exist, because the Height Correction record is redundant (since the Site Index tree record should already contain an accurate tree height measurement). Most times, you can just delete the redundant H1 record.
“Tree ORIGIN indicates natural regen., yet the tree is linked to Art. Regen. History.” –
(Affects C3 records) This means that the given RMT has an origin code that indicates natural (as opposed to artificial) regeneration. Either fix the origin code to the appropriate artificial origin, or remove the link to Artificial Regen. History.
“Tree ORIGIN indicates artificial regen., yet the tree is not linked to Art. Regen.
History.” – (Affects C3 records) This means that the given RMT has an origin code that
Page 7 of 11

indicates artificial (as opposed to natural) regeneration. Either fix the origin code to the appropriate natural origin, or link the tree to its appropriate Artificial Regen. History.
“Site was mechanically site-prepped, yet MPAPOS is null.” – (Affects C3 records)
According to the site prep history linked to the given RMT, the tree’s site was mechanically site prepped. All trees in a mechanically site prepped site must have a code for “Seedling Position on MPA”. To fix this, either enter the appropriate code for the tree, or change the tree’s site prep reference number to refer to the correct non-mechanical site prep history.
“Site was not mechanically site-prepped, yet MPAPOS is not null.” – (Affects C3 records) According to the site prep history linked to the give RMT, the tree’s site was not mechanically site prepped. In this case, the “Seedling Position on MPA” should be left blank. To fix this, either delete the tree’s MPA position code, or link its site prep history to a site prep record that indicates a mechanical site prep.
“The SPEC# field is not null, yet no WS# fields in corresponding L4 records have values.” – (Affects L3 records) On the Regeneration Surveys form, you’ve entered a species code in the “Healthy, Well-Spaced Species” line, but all the cells in the lines below the species code are blank. Either you’ve missed entering a number, or you’ve entered an unnecessary species.
“No matching L4 records exist.” – (Affects L3 records) On the Regeneration Surveys form, you’ve created a quadrant record and possibly entered a list of species codes in the
“Healthy, Well-Spaced Species” line, but no lines have been entered below. If you neglected to enter the data below the species list, enter it. Otherwise, there is no data for the quadrant in question, so delete the entire survey record for the quadrant.
“The primary key … is not unique.” – (Affects P2, P3, P4 records) On the Competition
Description form, you’ve entered a competition description for a tree/year combination that already exists in the TRENDS database. It is likely that you entered a tree’s latest competition description under a previous measurement year by mistake. If this is the case, then you must delete the competition with the mistaken measurement year and reenter it with the correct year.
“SOIL_TYPE_PIT does not match (one of) the pit(s) linked to the nearest gridpoint(s) (in table e4).” – (Affects T1 records) On the Site Disturbance form, you’ve entered a soil pit number in the Soil Type field that does not agree with the soil pit(s) that the ecoclassification description has linked to the gridpoint(s) nearest to the disturbance’s position. This error can only happen on installations where there is more than one soil pit.
The only way to fix this is to change the Soil Type number to one that matches the soil pit that the eco-classification links to (one of) the gridpoint(s) nearest to the disturbance’s position.
“No matching e4 record(s) exist.” – (Affects E3 records) In the Eco-classification form, you have entered an eco-class that is not linked to any gridpoint. Every eco-class must be
Page 8 of 11

linked to at least one gridpoint, so one way to correct the error is to link the eco-class to the appropriate gridpoint(s). Conversely, if the given eco-class does not appear at any gridpoint, then you should simply delete the eco-class, since it must not exist.
“SPECIES XXXXXXX does not appear in the Vegetation Description” – (Affects P3 records) On the Competition Description form, you have entered a species in the Top 5 competitors sub-form that was not entered in the Vegetation Description. The data-entry templates do their best to prevent this from happening, but under certain circumstances, it is still possible. There are at least two situations in which this error may arise:

You may have forgotten to enter the veg. species in the corresponding quadrant on the Veg. Description form. Enter it there, and the error is fixed.
 The RMT’s grid point may be adjacent to a compromised quadrant (or to the exterior of the installation), and the competing veg. species does not appear in the
Veg. Description (as it is either in a compromised quadrant or outside the installation). In this case, you should turn on the “Veg. Desc. Exempt” check box when entering the species in the Top 5 competitors. Refer to the TRENDS Data
Entry Template User Guide for more information about the “Veg. Desc. Exempt” check box.
Appendix A: TRENDS Database Table Names and Descriptions
Table Name Description
C3 Repeatedly Measured Tree: Header
C4 Repeatedly Measured Tree: Yearly Measurements
C5 Repeatedly Measured Tree: Harvest Reference Number
C6 Repeatedly Measured Tree: Site Preparation Reference Number
C8 Repeatedly Measured Tree: Artificial Regeneration Reference Number
C9 Repeatedly Measured Tree: Stand Tending Reference Number
CA Repeatedly Measured Tree: Annual Increment Measurements
CB Repeatedly Measured Tree: BC Stocking Standards Reference Number
CC Repeatedly Measured Tree: Alberta Survey Standards Reference Number
D1 Stand Description: Plot Header
D2 Stand Description: Tree Measurements
D3 Stand Description: Tree Damaging-Agent Codes
E0 Eco-Classification: Measurement Dates
E2 Eco-Classification: Zone, Subzone, Variant
E3 Eco-Classification: Eco-class (Site Series, Edatope)
E4 Eco-Classification: Link Eco-class and Soil Pit to Grid-point
G0 Cone Crop: Measurement Dates
G1 Cone Crop: Measurements
H1 Height Correction Tree
I0 Site Index: Plot Header
Page 9 of 11

Table Name
I1 Site Index Tree
Description
L0 BC Stocking/Free-Growing/Regen. Survey Dates
L1 Preparable/Plantable Spot Survey Measurement Dates
L3 BC Stocking/Free-Growing/Regen. Survey Species
L4 BC Stocking/Free-Growing/Regen. Survey Counts
L5 Preparable/Plantable Spot Survey
L6 Dropped Cone Survey
L8 Small Tree Description: Measurement Dates
L9 Small Tree Description: Quadrants (by Date)
LA Small Tree Description: Densities (by Date, Quadrant, Layer, and Species)
LB Small Tree Description: Damaging-Agents (by Date, Quadrant, Layer, and Species)
LC Dropped Cone Survey Measurement Dates
LD Alberta Regen/Free-to-Grow Survey: Measurement Dates
LE Alberta Regen/Free-to-Grow Survey: Tallest Seedlings by Species
LF Alberta Regen/Free-to-Grow Survey: Plot Status
LG Alberta Regen/Free-to-Grow Survey: Miscellaneous Info
M0 Multi-Story Heights and Ages: Plot Header
M1 Multi-Story Heights and Ages
N1 Administration and History: Plot Header
N2 Administration and History: Harvesting/Disturbance History
N3 Administration and History: Site Prep. History
N5 Administration and History: Artificial Regeneration History and Source
N6 Administration and History: Stand Tending History
N9 Administration and History: RMT (with CD) Selection Criteria
NB Administration and History: Compromised Quadrants
NC Administration and History: BC Specific Admin
NA Administration and History: RMT (without CD) Selection Criteria
ND Administration and History: Alberta Specific Admin
NE Administration and History: BC Stocking Requirements
NF Administration and History: Alberta Survey Standards
NG Administration and History: FIA Funding Information
P2 Competition Description: Header
P3 Competition Description: Top 5 Competitors
P4 Competition Description: Vegetation in 45-degree Cone by Layer
Q0 Quadrant Description: Measurement Dates (and Exposure)
Q1 Quadrant Description
R0 Root Disease: Measurement Dates
R1 Root Disease: Pre-Harvest
R2 Root Disease: Post-Harvest
S4 Soil Description: Soil Pit Header
S5 Soil Description: Humus Description
S6 Soil Description: Soil Horizons
S8 Soil Description: Depth to Restricting Layers and/or Unfavourable Subsoils
Page 10 of 11

Table Name Description
S9 Soil Description: Miscellaneous Information
T2 Site Disturbance: Measurement Dates
T3 Site Disturbance: Measurement Details
V2 Vegetation Description: Measurement Dates
V3 Vegetation Description: Layers (by Date)
V4 Vegetation Description: Layer Summaries (by Date and Quadrant)
V5 Vegetation Description: Layer Details (by Date, Species, and Quadrant)
W2 Coarse Woody Debris: Measurement Dates and Transect Lengths
W3 Coarse Woody Debris: Detailed Measurements
Page 11 of 11