interface supported: area

Showing posts with label area. Show all posts

Monday, March 26, 2012

normalization question

This question is inspired from my last question. It seems to me that for a
db to be properly normalized, should an area code be seperate from a phone
number? Is this incorrect?
SQL2K SP3
TIA, ChrisR
Probably not. The phone number really is (in North America) 10 digits, of
which the first three are the area code. Beyond N America, things change
somewhat (I believe).
That said, you can have a table of phone numbers where there is an area code
column and a number column, with a FK from the area code to a table of area
codes. This ensures that only known area codes are put into your phone
number table.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"ChrisR" <bla@.noemail.com> wrote in message
news:erXMq1M0EHA.2572@.tk2msftngp13.phx.gbl...
This question is inspired from my last question. It seems to me that for a
db to be properly normalized, should an area code be seperate from a phone
number? Is this incorrect?
SQL2K SP3
TIA, ChrisR
|||Actually, one could make an argument that both area code and prefix should
be separated out as keys, as they can be used to uniquely identify regions.
We use a database for that purpose, in order to determine qualification for
DSL. However, if you're only using them for display, they should definitely
be in the same column, IMO...
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:OxaITBN0EHA.2788@.TK2MSFTNGP15.phx.gbl...
> Probably not. The phone number really is (in North America) 10 digits, of
> which the first three are the area code. Beyond N America, things change
> somewhat (I believe).
> That said, you can have a table of phone numbers where there is an area
code
> column and a number column, with a FK from the area code to a table of
area
> codes. This ensures that only known area codes are put into your phone
> number table.
> --
> Tom
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com
>
|||I'd be careful about prefix. Where I work right now, I use 9+1+area
code+number. In another place, it was 4+area code+number. In yet another,
it was 8+area code+number. Of course, at home, it's 1+area code+number.
Sometimes, internationalization can be a right PITA...
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:urZFEGN0EHA.1332@.TK2MSFTNGP10.phx.gbl...
Actually, one could make an argument that both area code and prefix should
be separated out as keys, as they can be used to uniquely identify regions.
We use a database for that purpose, in order to determine qualification for
DSL. However, if you're only using them for display, they should definitely
be in the same column, IMO...
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:OxaITBN0EHA.2788@.TK2MSFTNGP15.phx.gbl...
> Probably not. The phone number really is (in North America) 10 digits, of
> which the first three are the area code. Beyond N America, things change
> somewhat (I believe).
> That said, you can have a table of phone numbers where there is an area
code
> column and a number column, with a FK from the area code to a table of
area
> codes. This ensures that only known area codes are put into your phone
> number table.
> --
> Tom
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com
>
|||>However, if you're only using them for display, they should definitely
> be in the same column, IMO...
Are you referring to the (ac and number), or the (ac and prefix) in this
statement?
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:urZFEGN0EHA.1332@.TK2MSFTNGP10.phx.gbl...
> Actually, one could make an argument that both area code and prefix should
> be separated out as keys, as they can be used to uniquely identify
regions.
> We use a database for that purpose, in order to determine qualification
for
> DSL. However, if you're only using them for display, they should
definitely[vbcol=seagreen]
> be in the same column, IMO...
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.sqljunkies.com/weblog/amachanic
> --
>
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:OxaITBN0EHA.2788@.TK2MSFTNGP15.phx.gbl...
of[vbcol=seagreen]
change
> code
> area
>
|||"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:ejuU7JN0EHA.3452@.TK2MSFTNGP14.phx.gbl...
> I'd be careful about prefix. Where I work right now, I use 9+1+area
> code+number. In another place, it was 4+area code+number. In yet
another,
> it was 8+area code+number. Of course, at home, it's 1+area code+number.
> Sometimes, internationalization can be a right PITA...
>
I think we're talking about different things in regards to prefix. I'm
talking about:
(XXX) YYY - ZZZZ
Where XXX is the area code and YYY is the prefix. For
internationalization it's:
+CC - (AreaCode) - (Prefix) - (Something)
(CC = Country Code)
AFAIK, there is always some sort of areacode and prefix, although the
number of digits are variable, but the something can be totally different
depending on country -- there may be more levels of hierarchy, e.g. I think
in some Asian countries they have 4 or 5.
The local phone system you're on will determine the prefix you're
talking about, 9 + 1, 4 + , etc.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
|||"ChrisR" <bla@.noemail.com> wrote in message
news:e8Do%23JN0EHA.1296@.TK2MSFTNGP10.phx.gbl...
> Are you referring to the (ac and number), or the (ac and prefix) in this
> statement?
AC and number. I would store it (if it were for display only) as:
XXXYYYZZZZ, or maybe XXX-YYY-ZZZZ, or however you might want to display
it on the client.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
|||Ah. Where we live, what you call "prefix" we call "exchange". So, I guess
in order to validate things, there would only be certain exchanges within an
area code.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23Bqf1TN0EHA.1524@.TK2MSFTNGP09.phx.gbl...
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:ejuU7JN0EHA.3452@.TK2MSFTNGP14.phx.gbl...
> I'd be careful about prefix. Where I work right now, I use 9+1+area
> code+number. In another place, it was 4+area code+number. In yet
another,
> it was 8+area code+number. Of course, at home, it's 1+area code+number.
> Sometimes, internationalization can be a right PITA...
>
I think we're talking about different things in regards to prefix. I'm
talking about:
(XXX) YYY - ZZZZ
Where XXX is the area code and YYY is the prefix. For
internationalization it's:
+CC - (AreaCode) - (Prefix) - (Something)
(CC = Country Code)
AFAIK, there is always some sort of areacode and prefix, although the
number of digits are variable, but the something can be totally different
depending on country -- there may be more levels of hierarchy, e.g. I think
in some Asian countries they have 4 or 5.
The local phone system you're on will determine the prefix you're
talking about, 9 + 1, 4 + , etc.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
|||Just as an FYI:

> For
> internationalization it's:
> +CC - (AreaCode) - (Prefix) - (Something)
> (CC = Country Code)
> AFAIK, there is always some sort of areacode and prefix
In Sweden, we have no prefix. We have CountryCode (obviously), AreaCode and "something". :-)
Are code can be from two to four numbers. "Something" can be from five to 8 or nine numbers (not
sure how many it can go to).
As one point, Sweden was bragging, I believe it was in Newsweek, that they have the longest
telephone numbers in the world. In a country with some 8.5 (at the time) mill people. I found that
partly amusing, and partly really really worrying...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23Bqf1TN0EHA.1524@.TK2MSFTNGP09.phx.gbl...
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:ejuU7JN0EHA.3452@.TK2MSFTNGP14.phx.gbl...
> another,
> I think we're talking about different things in regards to prefix. I'm
> talking about:
> (XXX) YYY - ZZZZ
> Where XXX is the area code and YYY is the prefix. For
> internationalization it's:
> +CC - (AreaCode) - (Prefix) - (Something)
> (CC = Country Code)
> AFAIK, there is always some sort of areacode and prefix, although the
> number of digits are variable, but the something can be totally different
> depending on country -- there may be more levels of hierarchy, e.g. I think
> in some Asian countries they have 4 or 5.
> The local phone system you're on will determine the prefix you're
> talking about, 9 + 1, 4 + , etc.
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.sqljunkies.com/weblog/amachanic
> --
>
>
|||And for further info, we don't have any prefix or area code in Denmark. We
used to have a 2 digit area code in the past, but for many years we've just
had an 8 digit phonenumber.
In the past I worked on deploying a CRM system to our offices worldwide.
That was sometimes quite a challenge to get the phone- and fax numbers
entered in the right way into the system due to all the differencies in
phone number syntax around the world.
Regards
Steen
Tibor Karaszi wrote:[vbcol=seagreen]
> Just as an FYI:
>
> In Sweden, we have no prefix. We have CountryCode (obviously),
> AreaCode and "something". :-)
> Are code can be from two to four numbers. "Something" can be from
> five to 8 or nine numbers (not sure how many it can go to).
> As one point, Sweden was bragging, I believe it was in Newsweek, that
> they have the longest telephone numbers in the world. In a country
> with some 8.5 (at the time) mill people. I found that partly amusing,
> and partly really really worrying...
> "Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in
> message news:%23Bqf1TN0EHA.1524@.TK2MSFTNGP09.phx.gbl...

normalization question

This question is inspired from my last question. It seems to me that for a
db to be properly normalized, should an area code be seperate from a phone
number? Is this incorrect?
SQL2K SP3
TIA, ChrisRProbably not. The phone number really is (in North America) 10 digits, of
which the first three are the area code. Beyond N America, things change
somewhat (I believe).
That said, you can have a table of phone numbers where there is an area code
column and a number column, with a FK from the area code to a table of area
codes. This ensures that only known area codes are put into your phone
number table.
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"ChrisR" <bla@.noemail.com> wrote in message
news:erXMq1M0EHA.2572@.tk2msftngp13.phx.gbl...
This question is inspired from my last question. It seems to me that for a
db to be properly normalized, should an area code be seperate from a phone
number? Is this incorrect?
SQL2K SP3
TIA, ChrisR|||Actually, one could make an argument that both area code and prefix should
be separated out as keys, as they can be used to uniquely identify regions.
We use a database for that purpose, in order to determine qualification for
DSL. However, if you're only using them for display, they should definitely
be in the same column, IMO...
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:OxaITBN0EHA.2788@.TK2MSFTNGP15.phx.gbl...
> Probably not. The phone number really is (in North America) 10 digits, of
> which the first three are the area code. Beyond N America, things change
> somewhat (I believe).
> That said, you can have a table of phone numbers where there is an area
code
> column and a number column, with a FK from the area code to a table of
area
> codes. This ensures that only known area codes are put into your phone
> number table.
> --
> Tom
> ---
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com
>|||I'd be careful about prefix. Where I work right now, I use 9+1+area
code+number. In another place, it was 4+area code+number. In yet another,
it was 8+area code+number. Of course, at home, it's 1+area code+number.
Sometimes, internationalization can be a right PITA...
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:urZFEGN0EHA.1332@.TK2MSFTNGP10.phx.gbl...
Actually, one could make an argument that both area code and prefix should
be separated out as keys, as they can be used to uniquely identify regions.
We use a database for that purpose, in order to determine qualification for
DSL. However, if you're only using them for display, they should definitely
be in the same column, IMO...
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:OxaITBN0EHA.2788@.TK2MSFTNGP15.phx.gbl...
> Probably not. The phone number really is (in North America) 10 digits, of
> which the first three are the area code. Beyond N America, things change
> somewhat (I believe).
> That said, you can have a table of phone numbers where there is an area
code
> column and a number column, with a FK from the area code to a table of
area
> codes. This ensures that only known area codes are put into your phone
> number table.
> --
> Tom
> ---
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com
>|||>However, if you're only using them for display, they should definitely
> be in the same column, IMO...
Are you referring to the (ac and number), or the (ac and prefix) in this
statement?
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:urZFEGN0EHA.1332@.TK2MSFTNGP10.phx.gbl...
> Actually, one could make an argument that both area code and prefix should
> be separated out as keys, as they can be used to uniquely identify
regions.
> We use a database for that purpose, in order to determine qualification
for
> DSL. However, if you're only using them for display, they should
definitely
> be in the same column, IMO...
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.sqljunkies.com/weblog/amachanic
> --
>
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:OxaITBN0EHA.2788@.TK2MSFTNGP15.phx.gbl...
of[vbcol=seagreen]
change[vbcol=seagreen]
> code
> area
>|||"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:ejuU7JN0EHA.3452@.TK2MSFTNGP14.phx.gbl...
> I'd be careful about prefix. Where I work right now, I use 9+1+area
> code+number. In another place, it was 4+area code+number. In yet
another,
> it was 8+area code+number. Of course, at home, it's 1+area code+number.
> Sometimes, internationalization can be a right PITA...
>
I think we're talking about different things in regards to prefix. I'm
talking about :
(XXX) YYY - ZZZZ
Where XXX is the area code and YYY is the prefix. For
internationalization it's:
+CC - (AreaCode) - (Prefix) - (Something)
(CC = Country Code)
AFAIK, there is always some sort of areacode and prefix, although the
number of digits are variable, but the something can be totally different
depending on country -- there may be more levels of hierarchy, e.g. I think
in some Asian countries they have 4 or 5.
The local phone system you're on will determine the prefix you're
talking about, 9 + 1, 4 + , etc.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--|||"ChrisR" <bla@.noemail.com> wrote in message
news:e8Do%23JN0EHA.1296@.TK2MSFTNGP10.phx.gbl...
> Are you referring to the (ac and number), or the (ac and prefix) in this
> statement?
AC and number. I would store it (if it were for display only) as:
XXXYYYZZZZ, or maybe XXX-YYY-ZZZZ, or however you might want to display
it on the client.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--|||Ah. Where we live, what you call "prefix" we call "exchange". So, I guess
in order to validate things, there would only be certain exchanges within an
area code.
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23Bqf1TN0EHA.1524@.TK2MSFTNGP09.phx.gbl...
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:ejuU7JN0EHA.3452@.TK2MSFTNGP14.phx.gbl...
> I'd be careful about prefix. Where I work right now, I use 9+1+area
> code+number. In another place, it was 4+area code+number. In yet
another,
> it was 8+area code+number. Of course, at home, it's 1+area code+number.
> Sometimes, internationalization can be a right PITA...
>
I think we're talking about different things in regards to prefix. I'm
talking about :
(XXX) YYY - ZZZZ
Where XXX is the area code and YYY is the prefix. For
internationalization it's:
+CC - (AreaCode) - (Prefix) - (Something)
(CC = Country Code)
AFAIK, there is always some sort of areacode and prefix, although the
number of digits are variable, but the something can be totally different
depending on country -- there may be more levels of hierarchy, e.g. I think
in some Asian countries they have 4 or 5.
The local phone system you're on will determine the prefix you're
talking about, 9 + 1, 4 + , etc.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--|||Just as an FYI:

> For
> internationalization it's:
> +CC - (AreaCode) - (Prefix) - (Something)
> (CC = Country Code)
> AFAIK, there is always some sort of areacode and prefix
In Sweden, we have no prefix. We have CountryCode (obviously), AreaCode and
"something". :-)
Are code can be from two to four numbers. "Something" can be from five to 8
or nine numbers (not
sure how many it can go to).
As one point, Sweden was bragging, I believe it was in Newsweek, that they h
ave the longest
telephone numbers in the world. In a country with some 8.5 (at the time) mil
l people. I found that
partly amusing, and partly really really worrying...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23Bqf1TN0EHA.1524@.TK2MSFTNGP09.phx.gbl...
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:ejuU7JN0EHA.3452@.TK2MSFTNGP14.phx.gbl...
> another,
> I think we're talking about different things in regards to prefix. I'
m
> talking about :
> (XXX) YYY - ZZZZ
> Where XXX is the area code and YYY is the prefix. For
> internationalization it's:
> +CC - (AreaCode) - (Prefix) - (Something)
> (CC = Country Code)
> AFAIK, there is always some sort of areacode and prefix, although the
> number of digits are variable, but the something can be totally different
> depending on country -- there may be more levels of hierarchy, e.g. I thin
k
> in some Asian countries they have 4 or 5.
> The local phone system you're on will determine the prefix you're
> talking about, 9 + 1, 4 + , etc.
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.sqljunkies.com/weblog/amachanic
> --
>
>|||And for further info, we don't have any prefix or area code in Denmark. We
used to have a 2 digit area code in the past, but for many years we've just
had an 8 digit phonenumber.
In the past I worked on deploying a CRM system to our offices worldwide.
That was sometimes quite a challenge to get the phone- and fax numbers
entered in the right way into the system due to all the differencies in
phone number syntax around the world.
Regards
Steen
Tibor Karaszi wrote:[vbcol=seagreen]
> Just as an FYI:
>
> In Sweden, we have no prefix. We have CountryCode (obviously),
> AreaCode and "something". :-)
> Are code can be from two to four numbers. "Something" can be from
> five to 8 or nine numbers (not sure how many it can go to).
> As one point, Sweden was bragging, I believe it was in Newsweek, that
> they have the longest telephone numbers in the world. In a country
> with some 8.5 (at the time) mill people. I found that partly amusing,
> and partly really really worrying...
> "Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in
> message news:%23Bqf1TN0EHA.1524@.TK2MSFTNGP09.phx.gbl...

normalization question

This question is inspired from my last question. It seems to me that for a
db to be properly normalized, should an area code be seperate from a phone
number? Is this incorrect?
--
SQL2K SP3
TIA, ChrisRProbably not. The phone number really is (in North America) 10 digits, of
which the first three are the area code. Beyond N America, things change
somewhat (I believe).
That said, you can have a table of phone numbers where there is an area code
column and a number column, with a FK from the area code to a table of area
codes. This ensures that only known area codes are put into your phone
number table.
--
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"ChrisR" <bla@.noemail.com> wrote in message
news:erXMq1M0EHA.2572@.tk2msftngp13.phx.gbl...
This question is inspired from my last question. It seems to me that for a
db to be properly normalized, should an area code be seperate from a phone
number? Is this incorrect?
--
SQL2K SP3
TIA, ChrisR|||Actually, one could make an argument that both area code and prefix should
be separated out as keys, as they can be used to uniquely identify regions.
We use a database for that purpose, in order to determine qualification for
DSL. However, if you're only using them for display, they should definitely
be in the same column, IMO...
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:OxaITBN0EHA.2788@.TK2MSFTNGP15.phx.gbl...
> Probably not. The phone number really is (in North America) 10 digits, of
> which the first three are the area code. Beyond N America, things change
> somewhat (I believe).
> That said, you can have a table of phone numbers where there is an area
code
> column and a number column, with a FK from the area code to a table of
area
> codes. This ensures that only known area codes are put into your phone
> number table.
> --
> Tom
> ---
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com
>|||I'd be careful about prefix. Where I work right now, I use 9+1+area
code+number. In another place, it was 4+area code+number. In yet another,
it was 8+area code+number. Of course, at home, it's 1+area code+number.
Sometimes, internationalization can be a right PITA...
--
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:urZFEGN0EHA.1332@.TK2MSFTNGP10.phx.gbl...
Actually, one could make an argument that both area code and prefix should
be separated out as keys, as they can be used to uniquely identify regions.
We use a database for that purpose, in order to determine qualification for
DSL. However, if you're only using them for display, they should definitely
be in the same column, IMO...
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:OxaITBN0EHA.2788@.TK2MSFTNGP15.phx.gbl...
> Probably not. The phone number really is (in North America) 10 digits, of
> which the first three are the area code. Beyond N America, things change
> somewhat (I believe).
> That said, you can have a table of phone numbers where there is an area
code
> column and a number column, with a FK from the area code to a table of
area
> codes. This ensures that only known area codes are put into your phone
> number table.
> --
> Tom
> ---
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com
>|||>However, if you're only using them for display, they should definitely
> be in the same column, IMO...
Are you referring to the (ac and number), or the (ac and prefix) in this
statement?
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:urZFEGN0EHA.1332@.TK2MSFTNGP10.phx.gbl...
> Actually, one could make an argument that both area code and prefix should
> be separated out as keys, as they can be used to uniquely identify
regions.
> We use a database for that purpose, in order to determine qualification
for
> DSL. However, if you're only using them for display, they should
definitely
> be in the same column, IMO...
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.sqljunkies.com/weblog/amachanic
> --
>
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:OxaITBN0EHA.2788@.TK2MSFTNGP15.phx.gbl...
> > Probably not. The phone number really is (in North America) 10 digits,
of
> > which the first three are the area code. Beyond N America, things
change
> > somewhat (I believe).
> >
> > That said, you can have a table of phone numbers where there is an area
> code
> > column and a number column, with a FK from the area code to a table of
> area
> > codes. This ensures that only known area codes are put into your phone
> > number table.
> >
> > --
> > Tom
> >
> > ---
> > Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> > SQL Server MVP
> > Columnist, SQL Server Professional
> > Toronto, ON Canada
> > www.pinnaclepublishing.com
> >
>|||"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:ejuU7JN0EHA.3452@.TK2MSFTNGP14.phx.gbl...
> I'd be careful about prefix. Where I work right now, I use 9+1+area
> code+number. In another place, it was 4+area code+number. In yet
another,
> it was 8+area code+number. Of course, at home, it's 1+area code+number.
> Sometimes, internationalization can be a right PITA...
>
I think we're talking about different things in regards to prefix. I'm
talking about:
(XXX) YYY - ZZZZ
Where XXX is the area code and YYY is the prefix. For
internationalization it's:
+CC - (AreaCode) - (Prefix) - (Something)
(CC = Country Code)
AFAIK, there is always some sort of areacode and prefix, although the
number of digits are variable, but the something can be totally different
depending on country -- there may be more levels of hierarchy, e.g. I think
in some Asian countries they have 4 or 5.
The local phone system you're on will determine the prefix you're
talking about, 9 + 1, 4 + , etc.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--|||"ChrisR" <bla@.noemail.com> wrote in message
news:e8Do%23JN0EHA.1296@.TK2MSFTNGP10.phx.gbl...
> >However, if you're only using them for display, they should definitely
> > be in the same column, IMO...
> Are you referring to the (ac and number), or the (ac and prefix) in this
> statement?
AC and number. I would store it (if it were for display only) as:
XXXYYYZZZZ, or maybe XXX-YYY-ZZZZ, or however you might want to display
it on the client.
--
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--|||Ah. Where we live, what you call "prefix" we call "exchange". So, I guess
in order to validate things, there would only be certain exchanges within an
area code.
--
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23Bqf1TN0EHA.1524@.TK2MSFTNGP09.phx.gbl...
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:ejuU7JN0EHA.3452@.TK2MSFTNGP14.phx.gbl...
> I'd be careful about prefix. Where I work right now, I use 9+1+area
> code+number. In another place, it was 4+area code+number. In yet
another,
> it was 8+area code+number. Of course, at home, it's 1+area code+number.
> Sometimes, internationalization can be a right PITA...
>
I think we're talking about different things in regards to prefix. I'm
talking about:
(XXX) YYY - ZZZZ
Where XXX is the area code and YYY is the prefix. For
internationalization it's:
+CC - (AreaCode) - (Prefix) - (Something)
(CC = Country Code)
AFAIK, there is always some sort of areacode and prefix, although the
number of digits are variable, but the something can be totally different
depending on country -- there may be more levels of hierarchy, e.g. I think
in some Asian countries they have 4 or 5.
The local phone system you're on will determine the prefix you're
talking about, 9 + 1, 4 + , etc.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--|||Just as an FYI:
> For
> internationalization it's:
> +CC - (AreaCode) - (Prefix) - (Something)
> (CC = Country Code)
> AFAIK, there is always some sort of areacode and prefix
In Sweden, we have no prefix. We have CountryCode (obviously), AreaCode and "something". :-)
Are code can be from two to four numbers. "Something" can be from five to 8 or nine numbers (not
sure how many it can go to).
As one point, Sweden was bragging, I believe it was in Newsweek, that they have the longest
telephone numbers in the world. In a country with some 8.5 (at the time) mill people. I found that
partly amusing, and partly really really worrying...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:%23Bqf1TN0EHA.1524@.TK2MSFTNGP09.phx.gbl...
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:ejuU7JN0EHA.3452@.TK2MSFTNGP14.phx.gbl...
> > I'd be careful about prefix. Where I work right now, I use 9+1+area
> > code+number. In another place, it was 4+area code+number. In yet
> another,
> > it was 8+area code+number. Of course, at home, it's 1+area code+number.
> >
> > Sometimes, internationalization can be a right PITA...
> >
> I think we're talking about different things in regards to prefix. I'm
> talking about:
> (XXX) YYY - ZZZZ
> Where XXX is the area code and YYY is the prefix. For
> internationalization it's:
> +CC - (AreaCode) - (Prefix) - (Something)
> (CC = Country Code)
> AFAIK, there is always some sort of areacode and prefix, although the
> number of digits are variable, but the something can be totally different
> depending on country -- there may be more levels of hierarchy, e.g. I think
> in some Asian countries they have 4 or 5.
> The local phone system you're on will determine the prefix you're
> talking about, 9 + 1, 4 + , etc.
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.sqljunkies.com/weblog/amachanic
> --
>
>|||And for further info, we don't have any prefix or area code in Denmark. We
used to have a 2 digit area code in the past, but for many years we've just
had an 8 digit phonenumber.
In the past I worked on deploying a CRM system to our offices worldwide.
That was sometimes quite a challenge to get the phone- and fax numbers
entered in the right way into the system due to all the differencies in
phone number syntax around the world.
Regards
Steen
Tibor Karaszi wrote:
> Just as an FYI:
>> For
>> internationalization it's:
>> +CC - (AreaCode) - (Prefix) - (Something)
>> (CC = Country Code)
>> AFAIK, there is always some sort of areacode and prefix
> In Sweden, we have no prefix. We have CountryCode (obviously),
> AreaCode and "something". :-)
> Are code can be from two to four numbers. "Something" can be from
> five to 8 or nine numbers (not sure how many it can go to).
> As one point, Sweden was bragging, I believe it was in Newsweek, that
> they have the longest telephone numbers in the world. In a country
> with some 8.5 (at the time) mill people. I found that partly amusing,
> and partly really really worrying...
> "Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in
> message news:%23Bqf1TN0EHA.1524@.TK2MSFTNGP09.phx.gbl...
>> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
>> news:ejuU7JN0EHA.3452@.TK2MSFTNGP14.phx.gbl...
>> I'd be careful about prefix. Where I work right now, I use 9+1+area
>> code+number. In another place, it was 4+area code+number. In yet
>> another,
>> it was 8+area code+number. Of course, at home, it's 1+area
>> code+number.
>> Sometimes, internationalization can be a right PITA...
>>
>> I think we're talking about different things in regards to
>> prefix. I'm talking about:
>> (XXX) YYY - ZZZZ
>> Where XXX is the area code and YYY is the prefix. For
>> internationalization it's:
>> +CC - (AreaCode) - (Prefix) - (Something)
>> (CC = Country Code)
>> AFAIK, there is always some sort of areacode and prefix,
>> although the number of digits are variable, but the something can be
>> totally different depending on country -- there may be more levels
>> of hierarchy, e.g. I think in some Asian countries they have 4 or 5.
>> The local phone system you're on will determine the prefix you're
>> talking about, 9 + 1, 4 + , etc.
>>
>> --
>> Adam Machanic
>> SQL Server MVP
>> http://www.sqljunkies.com/weblog/amachanic
>> --|||"Steen Persson" <SPE@.REMOVEdatea.dk> wrote in message
news:elA9%239V0EHA.3408@.tk2msftngp13.phx.gbl...
> And for further info, we don't have any prefix or area code in Denmark. We
> used to have a 2 digit area code in the past, but for many years we've
just
> had an 8 digit phonenumber.
> >
> > In Sweden, we have no prefix. We have CountryCode (obviously),
> > AreaCode and "something". :-)
Thanks for the info guys!
Both are countries I haven't worked with yet. I had a bear of a time w/
Asia (mostly due to lack of quality data, but it's been a few years since
that project so maybe things have improved) -- I can't wait until I get to
cover Europe :-)
--
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--

Friday, March 23, 2012

Noob here, dumb, but quick question

Ok, I know a LITTLE about SQL 2000. I am just starting to get my feet wet in the area. I know how to install SQL, backup DB's and Restore them. Can even do them over the network now. YAY ME! Anyway, here is my question. I have a production server with 4 RAID arrays. I have one for my OS, one for the Main SQL DB's (heavy transaction DB's), one for my log files, and one that is supposed to be for my temp DB. Well when I installed SQL it asked me for the default data path, which would be where my main SQL db's go. I dont remember it asking me where I want the temp DB to go. How do I change the location of the tempdb.mdf and tempdb.ldf to the drive arrays I want them to go to, even though I have already installed SQL.

Thanks. And sorry ahead of time for the noobiness of the question. I did do a search first, but didnt really see anything that would help me.To change where the data files are located for a given database, just right-click the database and change the Data Files and Transaction Log 'Properties'.

With that said, I don't remember if you can change the data file location for 'system' databases. So you might want to check into that...even so, I wouldn't expect any speed benefit from move the tempdb to a different location.

BTW, good question with some solid background for someone claiming to be noob.

Late,

Alexander|||We use this script for DR to relocate the tempdb to an array large enough to allow it to grow as needed. Change the paths and size to fit your situation, and don't forget to stop and restart the sever after altering the database.

use tempdb
alter database tempdb modify file (name = tempdev,
filename = 'T:\Program Files\Microsoft SQL Server\MSSQL\Data\tempdb.mdf', size = 10000 MB)
alter database tempdb modify file (name = templog,
filename = 'T:\Program Files\Microsoft SQL Server\MSSQL\Data\templog.ldf')|||http://support.microsoft.com/default.aspx?scid=kb;en-us;224071

As for me .. this link is permanently in my IE favourites folder ...

Friday, March 9, 2012

Non administrators running perfmon have no remote SQL counters

Not sure if i am posting this in the right area as although my symptoms
affect SQL they are probably not specifically limited to this. This could
probably be posted in Windows 2000 security area as well.
Server spec - HP Proliant server running Windows 2000 SP4, latest hotfixes
and fully patched, SQL Server 2000 and fully patched.
Database administration team wish to run system monitor / perfmon against
the server to baseline and monitor performance but segregation of duties
ensure that these can't be made local server administrators (I don't make the
rules I only try to work within them)
As an admin if I run perfmon locally on the server itself I can see all the
SQL performance objects. If I select counters from the computer remotely all
SQL counters are displayed - on this basis I know it is not a problem with
the performance counters themselves.
I have followed KB300702 to grant the non admin users access to perfmon
remotely and this works a treat except when the user fires up perfom and
lists the performance objects all of the SQL entries are missing. Even
though I have applied the access to the SQL service performance counters as
specified in the KB this still doesn't work.
I need to get this working without granting these users full administrator
rights or any of the other built in Windows groups OR without running the SQL
services with a different user ID /password and providing this to the
database team.
Any help that anyone can provide I will accept with extreme gratitudeHi
Windows 2000 is not listed as one of the platforms in this KB'
http://support.microsoft.com/default.aspx?scid=kb;en-us;152513
in particular permissions on
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
John
"Brian" wrote:
> Not sure if i am posting this in the right area as although my symptoms
> affect SQL they are probably not specifically limited to this. This could
> probably be posted in Windows 2000 security area as well.
> Server spec - HP Proliant server running Windows 2000 SP4, latest hotfixes
> and fully patched, SQL Server 2000 and fully patched.
> Database administration team wish to run system monitor / perfmon against
> the server to baseline and monitor performance but segregation of duties
> ensure that these can't be made local server administrators (I don't make the
> rules I only try to work within them)
> As an admin if I run perfmon locally on the server itself I can see all the
> SQL performance objects. If I select counters from the computer remotely all
> SQL counters are displayed - on this basis I know it is not a problem with
> the performance counters themselves.
> I have followed KB300702 to grant the non admin users access to perfmon
> remotely and this works a treat except when the user fires up perfom and
> lists the performance objects all of the SQL entries are missing. Even
> though I have applied the access to the SQL service performance counters as
> specified in the KB this still doesn't work.
> I need to get this working without granting these users full administrator
> rights or any of the other built in Windows groups OR without running the SQL
> services with a different user ID /password and providing this to the
> database team.
> Any help that anyone can provide I will accept with extreme gratitude|||John
Thanks for the response - you are correct in that the KB isn't listed as a
solution for Windows 2000 but a degree of commonality does exist - e.g. the
read permission required to the perflib area of the registry and the need for
full control on the performance key for each service.
The interesting bits (as I read it) seem to be that the remote counters are
running as a thread on the winlogon process and the idea that an issue with
an extensible DLL may be the problem - I will play around with this on my
test box and let you know how I get on.
Thanks again for your help
Brian
"John Bell" wrote:
> Hi
> Windows 2000 is not listed as one of the platforms in this KB'
> http://support.microsoft.com/default.aspx?scid=kb;en-us;152513
> in particular permissions on
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
> John
> "Brian" wrote:
> > Not sure if i am posting this in the right area as although my symptoms
> > affect SQL they are probably not specifically limited to this. This could
> > probably be posted in Windows 2000 security area as well.
> >
> > Server spec - HP Proliant server running Windows 2000 SP4, latest hotfixes
> > and fully patched, SQL Server 2000 and fully patched.
> >
> > Database administration team wish to run system monitor / perfmon against
> > the server to baseline and monitor performance but segregation of duties
> > ensure that these can't be made local server administrators (I don't make the
> > rules I only try to work within them)
> >
> > As an admin if I run perfmon locally on the server itself I can see all the
> > SQL performance objects. If I select counters from the computer remotely all
> > SQL counters are displayed - on this basis I know it is not a problem with
> > the performance counters themselves.
> >
> > I have followed KB300702 to grant the non admin users access to perfmon
> > remotely and this works a treat except when the user fires up perfom and
> > lists the performance objects all of the SQL entries are missing. Even
> > though I have applied the access to the SQL service performance counters as
> > specified in the KB this still doesn't work.
> >
> > I need to get this working without granting these users full administrator
> > rights or any of the other built in Windows groups OR without running the SQL
> > services with a different user ID /password and providing this to the
> > database team.
> >
> > Any help that anyone can provide I will accept with extreme gratitude|||Hi
There is also http://support.microsoft.com/?id=812915 which may not be your
problem but implies it could be worth apply the hotfix/service pack if you
have not already done so.
John
"Brian" wrote:
> John
> Thanks for the response - you are correct in that the KB isn't listed as a
> solution for Windows 2000 but a degree of commonality does exist - e.g. the
> read permission required to the perflib area of the registry and the need for
> full control on the performance key for each service.
> The interesting bits (as I read it) seem to be that the remote counters are
> running as a thread on the winlogon process and the idea that an issue with
> an extensible DLL may be the problem - I will play around with this on my
> test box and let you know how I get on.
> Thanks again for your help
> Brian
>
> "John Bell" wrote:
> > Hi
> >
> > Windows 2000 is not listed as one of the platforms in this KB'
> >
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;152513
> > in particular permissions on
> > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
> >
> > John
> >
> > "Brian" wrote:
> >
> > > Not sure if i am posting this in the right area as although my symptoms
> > > affect SQL they are probably not specifically limited to this. This could
> > > probably be posted in Windows 2000 security area as well.
> > >
> > > Server spec - HP Proliant server running Windows 2000 SP4, latest hotfixes
> > > and fully patched, SQL Server 2000 and fully patched.
> > >
> > > Database administration team wish to run system monitor / perfmon against
> > > the server to baseline and monitor performance but segregation of duties
> > > ensure that these can't be made local server administrators (I don't make the
> > > rules I only try to work within them)
> > >
> > > As an admin if I run perfmon locally on the server itself I can see all the
> > > SQL performance objects. If I select counters from the computer remotely all
> > > SQL counters are displayed - on this basis I know it is not a problem with
> > > the performance counters themselves.
> > >
> > > I have followed KB300702 to grant the non admin users access to perfmon
> > > remotely and this works a treat except when the user fires up perfom and
> > > lists the performance objects all of the SQL entries are missing. Even
> > > though I have applied the access to the SQL service performance counters as
> > > specified in the KB this still doesn't work.
> > >
> > > I need to get this working without granting these users full administrator
> > > rights or any of the other built in Windows groups OR without running the SQL
> > > services with a different user ID /password and providing this to the
> > > database team.
> > >
> > > Any help that anyone can provide I will accept with extreme gratitude

Monday, March 26, 2012

normalization question

normalization question

normalization question

Friday, March 23, 2012

Noob here, dumb, but quick question

Friday, March 9, 2012

Non administrators running perfmon have no remote SQL counters

Non administrators running perfmon have no remote SQL counters

Non administrators running perfmon have no remote SQL counters

interface supported

Blog Archive

About Me