Brian Barker wrote:
At 08:08 01/03/2010 -0800, Brewster Gillett wrote:
Brian Barker wrote:
Mind you, ZIP data should probably all be text, in fact.
That's an intriguing notion. Since ZIPs only ever consist of numbers,
why would it be preferable to store them as text? So as to avoid
confusion with "real" numbers?
Oh, because they are not numbers, but just labels with an accepted
collating order. I'm sure that Californians, with 9xxxx, see themselves
as three times as important as Georgians (3xxxx) and nine times New
Yorkers (1xxxx) - though they wouldn't like thinking that Alaska was
tops! But the codes don't have this numeric significance. And consider
Boston's Symphony Hall, with 02115: that leading zero is insignificant
in a number, and would be dropped, giving 2115; as part of a label, on
the other hand, the zero is more significant than any other of the digits.
Brian Barker
In other words: When the sum or average of the field is completely
pointless it must be some kind of identifier and deserves to be text.
In most cases you want IDs of different lenght to be sorted alphabetically :
1
12
123
2
21
212
(phone numbers anyone?)
For US ZIP codes in a database you could define a fixed text field with
5 characters and access the field through a pattern field on a form to
accept digits only.
Better: A list box bound to a list of all known US ZIPs with city names.
Then you would get the city name automatically.
In a spreadsheet this could be achieved by means of data validation with
VLOOKUP, but like all spreadsheet solutions, this is difficult to
maintain and breaks with copy/paste actions.
Andreas S.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
