The calculated value is invalid for the row with object id = 1

[ZachHewitt1]

I am currently running a large model and when I get to the part where there is a field calculation needed, it gives me this error. If I choose to continue running the model, it continues fine. It just seems to be at this part that the field calculation gets hung up. The problem occurs with the first row of data, which is no different from any of the other rows of data. Has anyone else ever had this issue?

[RichardFairhurst]

I am assuming this is all one calculation.  Try:

if (([SummaryStatistics.SUM_DrainArea_SF]) > 0 And ([SummaryStatistics.SUM_DrainArea_SF])) <= 299 then

n = "MINOR"

else

n = "COMPLIANT"

end if

if [Lat_Defects.ProposedWork] = "35" then

n = "XCONNECT"

end if

if ([Summary_Statistics_2.SUM_DrainArea_SF]) > 299 then

n = "MAJOR"

end if

Make sure your output field is text and at least 9 characters long so that it can hold the value "COMPLIANT".  If it is less than 9 characters long it will throw an error.  Are you sure all records in Lat_Defects have a matching record in both Summary_Statistics and Summary_Statistics_2?  Are you sure none of these 3 fields have Null values?  If any of them have an unmatched record or a Null value that will throw an error.  Have you checked that the join worked for both tables on the record with ObjectID 84 in the main table, especially if this is a 3-table join?

If you still have problems, you are going to have to at least post a screen shot of your data with the join in place, since it in not fair to ask us about errors that only occur for specific records if we cannot see those records.

[TedKowal]

Looks like the question is well handled.....

Just wanted to make a small observing comment.  I still find it a good idea to explicitly define/dimension all variables.  A lot of nasty type conversion errors can be avoided by explicitly knowing what type of variable you wish filled.

Another observation:   Dim n   "is not a string, integer, double or object"   In vb it is a "Variant" which could be any of all types.  I generally avoid variants except when I do not know what type of data that is being received into the variable.

[RichardFairhurst]

The Field Calculator uses VB Script which only supports type Variant.  If you try to Dim to any other type like string, integer, double, object, etc. an error will be thrown.  Using Dim is only a good practice in VBA or VB.Net, not VB Script.

[TedKowal]

New to me,  I am looking at various vbscripts I use with Dim statements....

Option Explicit

Dim MyArray()

ReDim AnotherArray().....

I do not disagree with VB Script using only Variant... properly Dim statements work and is good programming practice and helpful in debuging even VB Script

Simple example of why DIM is good programming practice

StudentFinalGrade = 100

StudentHomeworkGrade = 100

StudentCourseGrade = ((StudentFialnGrade + StudentHomeworkGrade)/200)*100

(Will not produce an error but is incorrect and the answer is wrong)  Difficult to debug

---------------------------------------------------------------

Option Explicit

Dim StudentFinalGrade, StudentHomeworkGrade

StudentFinalGrade = 100

StudentHomeworkGrade = 100

StudentCourseGrade = ((StudentFialnGrade + StudentHomeworkGrade)/200)*100

Will produce an error and the error is obvious [StudentFialnGrade should be StudentFinalGrade

[RichardFairhurst]

I could just as easily directly assign those variable names in VB Script without a Dim statement to an empty array at any point in my calculation, unlike VBA aand VB.Net where errors would occur if I did not explicitly cast the array to a real type, i.e, Dim MyArray() as String.  Using the syntax of VBA and VB.Net of Dim MyArray() as String throws an error and was the sole reason for months of posts on the forum after the release of 10.0 saying "My calculation broke at 10.0 and I don't know why".  So I stopped using it and have not had a problem debugging my calculations as a result.

Using Option Explicit has never been discussed on the forum that I can recall and I was unaware it had any effect in VB Script, so I never tried it.  That practice is not well established in any posts here on the forum or in the VB Script help.  Without the inclusion of that option, the use of Dim makes no difference.  So you needed to say that the use of Option Explicit is a good practice in conjunction with Dim, otherwise the statement about the value of Dim is misleading

Anyway, this user was misusing Dim by including it multiple times for the same variable name in his calculation.  That resets the variable, breaks the logic of having successive if statements and led to errors in the calculation, so using Dim like that is definitely a bad practice.

[TedKowal]