Much better is to make sure that this situation does not and can not arise by making sure that the data values are stored in numeric fields to begin with. You can see the scale of the issue of data conversion in Lotus Notes merely by looking at the huge range of data type checking and conversion built-in functions that exist in the Formula and LotusScript languages. Better than using them, avoid the whole need by storing the data in the right data type to begin with.

When users use your application
And of course, the best reason for determining that what appears to be a "number" is actually a text field will come when the business wants to store a value in it that isn't a number -- which, inevitably will happen after you've gone into production and not in testing.

Imagine that someone decided that the best way to store a telephone number is in a numeric field. It's a number, after all? And then your company decides that it is going overseas or into Europe, so phone numbers now need to be stored in international format. +44 (0) 1234 567890 isn't going to work in a number field and if it's then stored as 441234567890, it won't be easy for your users to read. I've yet to see a reason for doing arithmetic on telephone numbers. Do let me know if you can find one.

Using numeric fields is not without its dangers, however. Particularly in LotusScript it is all too easy to:

What's the problem with that? What if you forget that an integer can only cope with a maximum value of 32767? That one usually comes home to roost about a week after going in to production. Calculating time differences in seconds via NotesDateTime.TimeDiff will in the end catch you out, when the resulting value is more than can be put into a Single type variable. And I suspect that using Currency as a display type in Notes applications still catches people out when their application crosses into another country for the first time, and you learn that 1.00 UK pound is not remotely the same value the same as $1.00US or even 1.00 Euro.

Then there's the sorting issue, which does start, unless carefully handled, to blur the whole issue of numbers as arithmetic values or as strings that contain numeric characters. I have lost track of the number of times that I have seen Notes views which are mis-sorted, because the programmer expects that a number represented in text will sort as its numeric value would indicate it would.

But even this expectation comes down to what exactly the field value represents. Numbers are sorted by their numeric value; 1 before 2, and 9 before 10. However, if these were sorted as a string value, 1 would be before 2, but 10 would be between them. That's because string values are sorted character by character, left to right.

But, I can hear you saying that you actually want documents in a view sorted by some sort of ascending key -- a record or document number. And that the only way to sort such a list properly is by, well, numbering them in a numeric sequence.