field calc is off by one character,, by calculating the right4 characters from source field into blank 4 char long field it comes up 1 number wrong - 3 times in 220

[Anonymous User]

added cropped screen shot of what happens

two tables joined upon parcels

inactivenos and sourcenos

tsource  length 10 string

newno length 4

I have tried in python and vb

both come up with newno as being the next # higher

as though they were rounded up,

that in my humble opinion is like rounding "why" to "whz"

[JoshuaBixby]

Given the rounding appears to be happening with only a few records, and not all of the records, it makes me think something is up with the data at some level.  If there was a rounding bug in general, you would see many more or all of the rows being impacted.

What are the data sources of the two tables being joined?  File geodatabases?  Shape files?  Something else?

If you run the following code in the interactive Python window, what does it return for the 2 fields in question:

lyr = # layer or tableview name
desc = arcpy.Describe(lyr)
for fld in desc.fields:
    print fld.name, fld.type, fld.length, fld.precision, fld.scale‍‍‍‍

[Anonymous User]

Josh, both tables are in a file geodatabase, after some more digging and eye strain, the join i used had the potential to be one-to-many, even though the table viewed in the screen shot had the one number in it, a manual field calculate brought up the 'invisible' 2nd joined item, which just happened to be 'numerically' sequential.

Thanks for the reply

[MitchHolley1]

Is the field you're calculating from a Double type?

[Anonymous User]

Thanks Mitch for the inquiry, the fields were Text only, one field was 4 char in length the other was 10 char in length, It was a mistake (on my part) to presume what I saw was what I got, the join – based on parcels, was a 1 to many. The 3 miscalculations were just referencing a second point within the parcel which happened to be sequentially higher.