>> How would you cope with a contacts table that has to store data from international people? <<

Why is that a concern related to the issues presented?

I am not sure British "post codes" are the same thing as a zip-code anyhow. Perhaps either make a new field for them, or key the post-codes into the general address textbox.

If 98 percent of all contacts in the DB are U.S., then making special fields or formatting/validation for foreign addresses may not be worth the effort. As long as there is sufficient room to type them in when they do come up.

Making a truely international contact manager with full validation is an entire topic in itself. (I suggest you fork off a new discussion if you want to delve into that).

>> Because the American formatting rules you put there would reject a perfectly legitimate British post code, you numbskull. <<

Like an IF statement can't fix such?

If rs.country = Brits
....do this
else
....do this
end if


Of course a full-blown int'l system would have to be more systematic. Tables of potential fields and another "link" table of country's to match them to (and a 3rd Country table, of course). A 4th data table may resemble the link table, but with a Value field.

In practice, this is probably overkill except in high-end contact mgmt apps. Looking at the actual pattern, one would probably see there are ways to simplify it.


>> Whoopee, what a great idea! And then we add one column for every bloody country in the world that has different-format postal codes <<


It was only one suggestion among others. Whether we have different fields OR different validation rules for the *same* field is one of those design decisions that would have to be looked into by studying address patterns. If the fields were dynamically generated from a DD-like gizmo, then does not really matter.


>> B) So what's that "validation" _do_, then... If you can just "type them in when they do come up", with no regard to it?!? <<

I don't understand. In the simplest case you just:

If rs.Country = US
. . . validate
end if

IOW, turn off validation if non-US (under the 98% assumption).

Note that not all contacts may have complete info anyhow. IOW, you wouldn't want to force zipcode entry if the keyer does not have zipcode info available. Maybe just a warning. Going with this aproach, we may not need the above IF statement. A British zipcode would simply give a warning, which can be bypassed if not appropriate.

>> And can we have some example code to see how you handle writing adress labels from a database table with ~150 coulmns to choose the postal code from? <<

See above.

If you provide a more specific scenario, I would be glad to exchange psuedo-code with you. You would need to supply things like the country percentages expected, validation intensity needs, etc.

>> That's the second time you have this attitude. Please note that you are turning off validation when it is most useful: on rarely used format which, when mistyped, will cause maximum delay/pain. <<

A small company is generally *not* going to implement a system that checks every country's address for formatting errors.

Do you agree with this?

A large multinational company may indeed want such a system.

And there are millions of in-betweeners who have various ranges of non-US contacts and accuracy needs.

(There might be commercial components for this. I have not checked.)

It is continious. If you have a simple, generic solution for all-size biz's, then lets see it.

Otherwise, stick an object in your pie holes.

I didn't say otherwise. If I accidently implied it, I apologize.