Indeed, should you want to do arithmetic with such a field, an empty value -- which conventionally Lotus Notes stores as string "" rather than numeric NULL -- will generate an error. But that should be expected. You don't have a numeric value present, and if "" should be interpreted arithmetically as zero, then zero should actually be the value stored.

Inputting values
Next is the issue of inputting, accepting and storing a value. If the end-user is expected to enter a numeric value -- something that the application will do arithmetic with -- then give users a numeric field to enter it.

Lotus Notes, along with just about everything else, will deal with parsing the set of characters typed into the field into something that can be stored as a number. It will deal with all the keyboard characters that could be typed, and also when valid characters in invalid sequences are entered, it will handle them too.

An example of that is entering two or more periods in a numeric field -- assuming you use the US/UK convention on numeric entry, that is. Our European cousins use a comma as the decimal divider and periods as numeric separators, and Notes and Windows deal with that transparently for them, and us.

This all means that by the time the entered value gets stored, or is passed to any field validation or translation formula you might write, it will be a number value. The one exception to this is that Lotus Notes will accept no entry as a valid value for a number field, but will then store the value as text "", which won't help subsequent arithmetic operations. In such a case, add the following as a translation formula:

This will ensure that if no value is entered, a zero will be stored. Subsequent arithmetic operations will be safe, except of course a divide-by-zero operation. You will, of course, have made provisions for possible zero divide situations, won't you?

Type conversion
There's another good reason to keep arithmetic field values in numeric fields rather than in text, and that's type conversion. Type conversion is inherently slow, because it has to be able to take any possible value from the source field and convert it to the target. That's a complex operation, particularly if the source is of string or text type, because of all the characters that could be in the field value.

So if we have to do it, it's best to do it once, at the point that the value first appears as a non-numeric value into the application, which in itself tends to be at the point of initial data entry. And at that point, as we have just seen, Lotus Notes will do the data validation for you anyway.

But if you can't avoid type conversion in your application, you must remember that you need to guard against source values that cannot be converted to numeric. You also need to take into account those that can be converted, but have values too big for the numeric type you are using. You must also supply a default value when the conversion fails.