>>>>Thanks Nancy, but this is not an international app. It's just a mailing list that mails to people all over the
>>>>world.
>>>>
>>>>Bill
>>>>
>>>>>I don't have a direct suggestion except to suggest you look at www.stevenblack.com for tools specifically geared toward international apps.
>>>>>
>>>>>>I'm trying to decide whether to store zip codes and phone #s in the dbf with or without the formatting characters.
>>>>>>
>>>>>>I have a client who needs to store American, Canadian, Mexican and various European zip/postal codes
>>>>>>and phone #s.
>>>>>>
>>>>>...snip
>>
>>>I would just store the formatting characters. Disk space is not hard to come by nowadaze. Then when you output the information, you don't have to remember to run it through any function to display it properly. But I suppose there would be arguments for any solution...
>>>
>>>Joe
>>>
>>
>>Now for the problem with that.
>>How do you generically recognize whether a field is empty or not? If the formatting characters are part of
>>the data then an empty fax field MIGHT be stored as "() -". Again, remember that a report would not know
>>what format the # was in, so how would it know it's empty, and not print it?
>>
>>I'm reaching the conclusion that I agree with you. I think the overpowering argument is the problems with
>>displaying them in a grid. I don't think there is any way to have the different InputMasks work on different
>>rows in the grid. The entire column would have to use the same InputMask.
>>
>>Any other ideas anyone?
>>
>>Bill
>BTW for determining an empty field with codes like ()- etc if(empty(chrtran(cField,"()-/\"," "))) would help.

Nice thought, but I think I've reached the conclusion to keep the InputMasks in a separate table and just store
the data itself. The only significant problem I see with doing it this way is solved by the DynamicInputMask
property as everyone pointed out.

Bill