How do I get Access to display a UK telephone number?

[Dave Walling]

How do I get Access to display a UK telephone number, without truncating it?
IE. 01223456789 is displayed as 1223456789. No matter what I try it either
does this or throws up an error message. Any help would be grateful as I am
new to this side of computing.

 

[Pieter Wijnen]

easiest is to store it in a text field..
else use the format property .

Pieter

 

[Sheila D]

I guess the field is formatted as a number which normally drops leading
zeros. I'd format it as Text then you can include spaces in your telephone
numbers as well

HTH - Sheila

 

[torch_music]

Dave,
First thing is that you need to ensure that the field you are saving the
data in is a text field, if Access thinks it is a number field it will lose
the leading zero, the next thing you can do is use an input mask to get a US
style telephone number format (0123) 456 7890 or create a custom one
depending on how you wish to display the data.
Hope this helps
Peter

 

[(PeteCresswell)]

01223456789 is displayed as 1223456789. No matter what I try it either
does this or throws up an error message. Any help would be grateful as I am
new to this side of computing.

As others have suggested: make it a "Text" field.

Also, I'd avoid trying to be cute with formatting. Just store whatever the user
types in and do not try to format it. Reason: you can get bogged down with
extension formats, international dialing codes, and other unexpected additions
to the raw number.

 

[Rick Wannall]

As Pete says, echoing others, make it a text field. A phone number field is
only incidentally filled with numbers. No calculation is done on these
numbers, so trying to keep it a numeric field does nothing but keep you from
being able to format it the way you want to see it.

I also second storing exactly what the user types in unless there is a
compelling reason to format. If there is, then it will be worth the time it
takes to add a column somewhere (probably the Country column, which may
already exist), and write a function such as this:

Public Function FormatMyPhone(MyCountry as string, MyNumber as string) as
string

select case MyCountry
Case "CA"
...formatting code here
Case "USA"
...formatting code here
Case "Mexico"
...formatting code here
Case Else
FormatMyPhone = MyNumber
end select

exit function

end function

In the afterupdate event of the phone number textbox, you store the
formatted value using a call to your function. Then, store exactly that.

 

[torch_music]

Agreed you need to store what the user types in, but you should give some
thought to validation of the data. For example there should not be any alpha
characters in the data, so you should check for that especially instances of
users mistakenly entering a capital i 'I' instead of a one '1'. It does
happen. But also bear in mind that some people enter numbers in the following
format +44 (207) 123 1234. Do you want to store the + sign? Do you want to
store the spaces? That is why I was recommending the use of an input mask, it
guides the user in how you want them to enter the data so that you end up
with some consistency, but behind the scene you control how the actual data
is stored in the database.

 

[(PeteCresswell)]

Per torch_music:

Agreed you need to store what the user types in, but you should give some
thought to validation of the data. For example there should not be any alpha
characters in the data, so you should check for that especially instances of
users mistakenly entering a capital i 'I' instead of a one '1'. It does

But why? Assuming the info is not tb used by autodialers - just by people....

e.g. 011-44-51-296-1000 x43

and

610-297-0953, "George"


Could both be legitimate, useful numbers for a user.


Or even "(e-mail address removed)"..... assuming that some users
might want to use the field as a "contact node" and not just a phone number.

 

[torch_music]

Because it leads to cleaner data in your database; the old axiom garbage in
garbage out still applies.
The storage of the data is separate to the presentation of the data. Do you
need to store dashes and spaces and plus symbols in the database? I would say
no, they are not intrinsic values of the data; they are presentation
preferences and as such do not need to be stored.
You will save a bit of space in the database, how much depends on how many
numbers are stored. One or two bytes per number is not much when you only
have twenty numbers stored, but when you have 20,000 or 200,000 those extra
bytes can add up.
it makes indexing more efficient by having more consistency in your data.
Since it is a text field it will make searching easier, if you do not have
some validation in there then you are dependant on the whim of the user when
they entered the data. Are you going to search for 0207 123 1234 or
0207-123-1234 or +44 (207) 1231234? You will need to know how the user
entered the value otherwise you will not be able to retrieve it if you dont
have validation and consistency.
Dave specifically asked about UK telephone numbers, email addresses are a
completely different issue. In that case it is much harder to build in
validation because the range of acceptable characters in an email address is
pretty much anything except a control character (yeah its a sweeping
statement but without doing some serious research I dont think I am that far
off the mark)

"George" - legitimate; really? You'd have to convince me on that one.

"x43" This is an interesting one and I think is a design decision that needs
to be made. Are extentsion numbers going to be part of the 'main' telephone
number or are you going to store them in a separate field?

 

[(PeteCresswell)]

Per torch_music:

"George" - legitimate; really? You'd have to convince me on that one.

Not to us.... but to the user.

 

[quest]

Phone Directory
http://www.earthsketch.com/phone_dir.php
International Dailing Codes
http://www.earthsketch.com/intr_codes.php
Nation Wide Dailing Codes
http://www.earthsketch.com/nwd_codes.php



Afghanistan 93
Albania 355
Algeria 213
American Samoa 684
Andorra 376
Angola 244
Anguilla -25
Antarctica 672
Antigua and Barbuda -25
Argentina 54
Armenia 374
Aruba 297
Australia 61
Austria 43
Azerbaijan 994