473,386 Members | 1,733 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,386 software developers and data experts.

Hyphenated Name Field

I have designed databases but have never come across any complications due
to the ridiculous situation of a hyphenated last name. As a database
designer (very junior level) I disdain anything unwieldly, and consider this
unwieldly.

I haven't dealt with it, as I said, but I figure if I do, I'd simply design
the text field to not accept hyphens, so Smith-Barney would be stored as
SmithBarney, or even Smithbarney as I commonly have the forms automatically
apply a Title Case to everything entered.

It is standard practice in many databases to leave such characters out, in
phone numbers for example even when an "input mask" is designed and it's
prompting you how to do everything and it asks you if you want to store the
hyphens the default is that it doesn't. This seems to be the smarter way to
go, as it prevents formatting pecularities from messing up searching &
sorting etc.

Is this how Smith-Barney should be dealt with--prevent the hyphen? Or would
feminazist-clients become too upset?

PS--this is NOT a troll message, not trying to upset anyone--again, I have
designed databases and am asking as such, as I have never come across this
yet but figure one day I will

LRH
Nov 13 '05 #1
14 5469
On Thu, 26 May 2005 22:39:09 -0700, "Larry R Harrison Jr"
<no***@noone.com> wrote:

I prefer to deal with field values as they are. If that means writing
extra code to handle Smith-Barney or O'Brien, so be it.
Masks is a different situation. You can store them, or not. Just be
consistent.

-Tom.

I have designed databases but have never come across any complications due
to the ridiculous situation of a hyphenated last name. As a database
designer (very junior level) I disdain anything unwieldly, and consider this
unwieldly.

I haven't dealt with it, as I said, but I figure if I do, I'd simply design
the text field to not accept hyphens, so Smith-Barney would be stored as
SmithBarney, or even Smithbarney as I commonly have the forms automatically
apply a Title Case to everything entered.

It is standard practice in many databases to leave such characters out, in
phone numbers for example even when an "input mask" is designed and it's
prompting you how to do everything and it asks you if you want to store the
hyphens the default is that it doesn't. This seems to be the smarter way to
go, as it prevents formatting pecularities from messing up searching &
sorting etc.

Is this how Smith-Barney should be dealt with--prevent the hyphen? Or would
feminazist-clients become too upset?

PS--this is NOT a troll message, not trying to upset anyone--again, I have
designed databases and am asking as such, as I have never come across this
yet but figure one day I will

LRH


Nov 13 '05 #2
On Thu, 26 May 2005 22:39:09 -0700, Larry R Harrison Jr wrote:
I have designed databases but have never come across any complications due
to the ridiculous situation of a hyphenated last name. As a database
designer (very junior level) I disdain anything unwieldly, and consider this
unwieldly.

I haven't dealt with it, as I said, but I figure if I do, I'd simply design
the text field to not accept hyphens, so Smith-Barney would be stored as
SmithBarney, or even Smithbarney as I commonly have the forms automatically
apply a Title Case to everything entered.

It is standard practice in many databases to leave such characters out, in
phone numbers for example even when an "input mask" is designed and it's
prompting you how to do everything and it asks you if you want to store the
hyphens the default is that it doesn't. This seems to be the smarter way to
go, as it prevents formatting pecularities from messing up searching &
sorting etc.

Is this how Smith-Barney should be dealt with--prevent the hyphen? Or would
feminazist-clients become too upset?

PS--this is NOT a troll message, not trying to upset anyone--again, I have
designed databases and am asking as such, as I have never come across this
yet but figure one day I will

LRH


Personally, I think it's disrespectful to a person to write his/her
name as anything other than the way that person want's to see it.
Smithbarney is not the same as Smith-Barney. If I was Mr. Smith-Barney
and received a letter with my name improperly spelled like that I
would not be favorably inclined towards whatever the letter was about.

You state that you are using 'Title Case' (StrConv I assume).
Are you concerned with names like O'Brien and Smith-Barney being
improperly capitalized as O'brien and Smith-barney?
It's no problem to write a User Defined function to check for a hyphen
within a name and capitalize the next character if that is your
concern. A table of name exceptions does well with names like
O'Brien (as well as McDonald and van den Steen).

--
Fred
Please only reply to this newsgroup.
I do not reply to personal email.
Nov 13 '05 #3
I have a problem having to write code specifically for this special
situation, when all other names don't need it. Why should code have to
be written for such specific situations--code which will only add bloat
and complexity?

Databases work best when data goes where it is supposed to--and
conforms to a certain standard. That's why so many systems make you not
enter hyphens, or extra spaces, or enter the first name in the first
name field as opposed to your middle name there because you like going
by your middle name rather than 1st name. If everyone would just do
things the same way, you wouldn't have to program for the
complexity--and I like how things like government forms don't
accomodate and make people who go by their middle name--say "Larry
Reynolds Harrison" goes by Reynolds--they nonetheless fill out "Larry R
Harrison" just the same--they don't accomodate for the special
circumstance because it adds too much complexity, those exceptions
shouldn't compromise or complicate the other data.

Trust me, I don't have an attitude towards personal preferences--as
long as they don't add special complications that 95% of other
situtaions don't. Why should someone think they're so special by having
a hyphenated name that an entire database & its system has to be
altered to accomodate them when everyone else's normal situations don't
require this? That is what I have the problem with--and I kind of like
systems which don't. Maybe I'm sick, I don't know--I know that those
who design databases are there to help & not hinder, but you kind of
need the cooperation of the client to not bend things too much to help
towards this end.

LRH

Nov 13 '05 #4
la********@yahoo.com wrote:
I have a problem having to write code specifically for this special
situation, when all other names don't need it. Why should code have to
be written for such specific situations--code which will only add bloat
and complexity?
I agree with Tom van Stiphout and fredg. Hyphenated last names were
not invented to frustrate programmers. They are real data. If the
strConv function can't handle capitalization of the real data then you
have to find another way to make it happen. Trying to apply political
pressure to persuade the client into accepting something that is not
real data because you can't handle the complexity is backwards IMO.
systems which don't. Maybe I'm sick, I don't know--I know that those
who design databases are there to help & not hinder, but you kind of
need the cooperation of the client to not bend things too much to help
towards this end.


So is the thinking that the client would be bending things by asking
that this situation be handled.

James A. Fortune

Nov 13 '05 #5
On 1 Jun 2005 11:21:33 -0700, la********@yahoo.com wrote:
I have a problem having to write code specifically for this special
situation, when all other names don't need it. Why should code have to
be written for such specific situations--code which will only add bloat
and complexity?
Big Snip

I may be at the other end of the spectrum. I don't try to make any
one-size-fits-all formatting rules for text fields. If the data entry person
enters the first character as lower case for a proper name, it stays lower
case. On the other hand, if the first character after a hyphen is capitalized,
it stays that way too. I don't think it is too much too ask that the data
entry person use proper grammatical rules. So far, at least, it's not against
the law to think about what you are doing at your job.

Just a wizard prodder
Chuck
--

Nov 13 '05 #6

<ji********@compumarc.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
So is the thinking that the client would be bending things by asking
that this situation be handled.

James A. Fortune

In some cases, absolutely. For example, I have actually had persons before
wonder how come their attempts to enter data crashed when they tried to
enter the state in the Zip code. They enter some names as "O'Brien" and
others as "OBrien" and still others as "O Brien"--only to then wonder why
not all of those are sorted together as if they're the same. They wonder how
come a query they later add themselves for showing "O'Brien" returns
inaccurate numbers because of the other variations entered.

Duh! You have to be consistent, enter them all the same way.

Then of course you have drop-down lists for states commonly, because some
will enter "NC" some "N.C." some "nc" and on and on. You have to be
consistent, else search results and the like will be off. You wouldn't
expect me to design the query to say "NC" or "nc" or "n.c." or "N C" or "Nc"
and on & on, would you? I would surely hope not.

Simply enough--with data, you have to have consistency with such things. It
would be ridiculous to ask a designer to allow for these variations. What I
will do instead--and others apparently do likewise--is design the database
to FORCE the user to enter all such entries identically. Not sure how one
would do this with the O'Brien issue--unless they made it unable to accept
the ' character or spaces of any kind--but with states, again, commonly a
drop-down list of states would be attached to the "state" field, with the
"limit to list" attribute set to "yes."

To me, this is such a situation. If you have some who would call themselves
"Smith Barney," others who would call themselves "Smith-Barney" others who
would have some other variation--you end up complicating things. If you
search for those whose true last name is "Barney," for instance, you may
pull up "Smith-Barney" in there as well undesirably--if you are doing one of
those "Like "*" And [name] and "*" type of searches.

Simply enough, it adds complexity where it isn't needed. I think that is
why, for instance, I hear that when my brother in law who I shall call "John
George Smith"--we likes to go by George rather than John--he has to enter
forms "John G Smith," because they ask for his middle initial ONLY, they do
not care what his middle name is, even though that's what he goes by. To
MAKE SURE he gets found in important searches, they make him along with
everyone else enter his first name in full, his middle initial ONLY, then
his last name--period. No exceptions, whatsoever. I would guess if his last
name was "Jones-Barney" they would have him fill out the form "JonesBarney"
and that's how it would get entered.

I like such designs, personally. And I figure--I don't know, but if people
like "George" can be understanding of such realities with government forms &
the databases that hold the data, why should we do any differently? The
conformity is a GOOD thing--increases the probability of the data being
obtained properly and quickly, and helps prevents "cross contamination" of
data with similar names. In other words--data integrity. Isn't that the
point? If overly-sensitive types are wanting to compromise this to save
their sensibilities, I say they need a reality check.

In closing--I typically post here with extremely practical questions, not
opiniated ones. I typically ask questions like "what syntax is appropriate
for creating a joint query in SQL." I will make sure to stick to such
questions in the future for the most part and hopefully not waste anyone's
time here; I realize Microsoft MVPs and the like are hanging out here to
help & don't want to get sucked into long-winded opinion discussions. I am
asking as a designer, not trying to be opiniated politically so much as that
the objective here is the protection of data integrity, not sucking up to
people's whimsical fascination with titles & so forth.

LRH
Nov 13 '05 #7
I do hear you. Sometimes giving a certain field "room" to be "loose" may be
the way to go. I know that recently I was actually a data-entry clerk at a
job assignment but I designed a form which converted what I entered to title
case--and it very significantly increased my speed.

I think maybe an unbound check box which, if checked, does NOT execute the
StrConv function in the name field, could be utilized as an override option;
if not checked, the last name would be converted, if checked, it would not
be. It could have an &h caption or something so the data-entry person could
type ALT-H to toggle this switch off & on without having to use the mouse &
slow his/her data-entry down.

LRH
Nov 13 '05 #8
Larry R Harrison Jr wrote:
I think maybe an unbound check box which, if checked, does NOT execute the
StrConv function in the name field, could be utilized as an override option;
if not checked, the last name would be converted, if checked, it would not


If you've data entry experience as you say, then you'll know anything
optional is always forgotten by data entry clerks.

Go with Chuck's method. Some data entry people may be misogynist as you
demonstrated in your OP, but most are not stupid.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Nov 13 '05 #9
"Tim Marshall" <TI****@PurplePandaChasers.Moertherium> wrote in message
news:d7**********@coranto.ucs.mun.ca...
Go with Chuck's method. Some data entry people may be misogynist as you
demonstrated in your OP, but most are not stupid.
--

As I said to Chuck, his way (which is, anything goes in such fields) may
well be the way. It is a delicate balance between controlling how the data
are input so as to keep it "normalized," vs giving flexibility so that
what's needed to be entered can be. That said, the misogynist label doesn't
apply. I don't hate women, I hate strays from the norm which complicate
things, whichever gender is the one doing it. Gender is irrelevant.
Conformity and data-integrity are what matter, not feelings.

LRH
Nov 13 '05 #10
Larry R Harrison Jr wrote:
I hate strays from the norm which complicate
things,


And that's what you will always have to contend with as a DB developer.

8)

Be prepared for furrowed foreheads of clients who are upset when they
discover a miniscule fraction of data is not dealt with. Those clients
will view such an app as garbage and will be unable to appreciate the
work and elegance you may have driven yourself into the ground to
provide... just because of that small fraction. Been there, done that. 8(
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Nov 13 '05 #11
Thanks for the heads-up. It does sound like something I'd encounter. I can
see it now--people flipping out because they try to enter "piou0" in the ZIP
CODE field and expecting it will magically recognize it as valid & process
it somehow.

I did have something happen a few years ago, when I designed a database to
import data from an Excel sheet but then it couldn't because the data came
"un-normalized," I basically would've had to "dumb down" my design to import
his data. It would have resulted in un-normalized data, insomuch that the
sales table would've had the names and addresses & phone numbers of each
sales client, when it had been designed to have a separate table for these
clients with only the id field of the client linked in the sales table. I
consulted on the newsgroup--should I "dumb down" my design so it could
import the data, or keep it & explain to the client that he needed the
supplier of the data to supply it in a slightly different format to be more
compatible with my database. Every last poster here voted the latter, and
that's what I did. I did so kindly, but it's what I did.

I lost the client. But I figured--I shouldn't dumb down my database,
especially since doing so would remove many of the features he had actually
been the one to ask for. I did later on, as my expertise improved, learn how
I could've actually done this for him. But at the time I couldn't. Live &
learn.

LRH
"Tim Marshall" <TI****@PurplePandaChasers.Moertherium> wrote in message
news:d7**********@coranto.ucs.mun.ca...
Larry R Harrison Jr wrote:
I hate strays from the norm which complicate things,


And that's what you will always have to contend with as a DB developer.

8)

Be prepared for furrowed foreheads of clients who are upset when they
discover a miniscule fraction of data is not dealt with. Those clients
will view such an app as garbage and will be unable to appreciate the work
and elegance you may have driven yourself into the ground to provide...
just because of that small fraction. Been there, done that. 8(
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

Nov 13 '05 #12
Larry R Harrison Jr wrote:
<ji********@compumarc.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
So is the thinking that the client would be bending things by asking
that this situation be handled.

James A. Fortune

In some cases, absolutely. For example, I have actually had persons before
wonder how come their attempts to enter data crashed when they tried to
enter the state in the Zip code. They enter some names as "O'Brien" and
others as "OBrien" and still others as "O Brien"--only to then wonder why
not all of those are sorted together as if they're the same. They wonder how
come a query they later add themselves for showing "O'Brien" returns
inaccurate numbers because of the other variations entered.

...

In closing--I typically post here with extremely practical questions, not
opiniated ones. I typically ask questions like "what syntax is appropriate
for creating a joint query in SQL." I will make sure to stick to such
questions in the future for the most part and hopefully not waste anyone's
time here; I realize Microsoft MVPs and the like are hanging out here to
help & don't want to get sucked into long-winded opinion discussions. I am
asking as a designer, not trying to be opiniated politically so much as that
the objective here is the protection of data integrity, not sucking up to
people's whimsical fascination with titles & so forth.

LRH


Opinions aside, if O'Brien, OBrien and O Brien are truly equivalent as
demonstrated by a table containing numerous misspellings then you can
run a query on that table to create tblAlternates as a way of merging
the variants.

tblPeople
PersonID PK
LastName Text
....

55 O'Brien

tblAlternates
AltID PK
VariantID FK
Preferred Y/N
NameVariant Text

21 8 -1 O'Brien
22 8 0 OBrien
23 8 0 O Brien

Obviously Preferred will be -1 for the preferred variation. You also
need to take requisite care that two different last names don't have
variants that are spelled the same.

Then in the AfterUpdate event of cbxLastName you can use SQL such as:

"SELECT NameVariant FROM tblAlternates WHERE VariantID IN (SELECT
VariantID FROM tblAlternates WHERE NameVariant = " & Chr(34) &
cbxLastName.Value & Chr(34) & ") AND Preferred = -1;"

If this SQL string returns a value you can replace the value entered in
cbxLastName with the the preferred version of the last name. At least
this way you only have to deal with variants that are new.

Opinions on. If people want whimsical titles then our sense of
protection of data integrity should protect those fanciful titles also.
Let someone else burst their bubble. Put the money in your wallet.

James A. Fortune

I will be following this closely:
Earlier this week, Microsoft Chairman Bill Gates said Longhorn, due in
2006, will have a new XML-based document format, code-named "Metro,"
that will be used to both print and share documents.
-- C|Net April 27, 2005

Nov 13 '05 #13

If you don't hate women, perhaps you should not assume that those with
hyphenated names are "feminazis" (as you called them in another post).
Since this is a derogatory term, your use of it distinguishes you as a
mysogynist.

Major error: hyphenated names were not invented by feminists or
feminism. They are very common. Actress Julia Louis-Dreyfus, for
example, has a hypenated name with which she was born. She didn't pick
a hyphenated name. It IS her name. She didn't pick it to make a
feminist statement or to annoy some lowly coder.

Further, plenty of men (such as Julia Louis-Dreyfus' brother and father)
have hyphenated names. Also, many commercial firms use similar
nomenclature (such as in the Smith-Barney example).

It is simply childish to characterize common customs as some sort of
personal affront to you. Further, I think your attitude as a developer
absolutely stinks. Your job is to help the client acheive their goals,
not to scold them for not conforming to your narrow view of the world as
you think it should be. As a developer, I think I have to find a way to
make the data work from the form to the data entry to the queries and to
the reports. That's MY problem and it's my job to solve it.
Accomodations to exceptions are a small price to pay when compared to a
disappointed client.

Were I your client or your supervisor, I'd fire you for your "can't-do"
attitude. Your mysogyny and borderline racism - yes, hyphenated names
are common to people with certain types of national origin - are
unacceptable and expose your employer and your client to liability. You
would be SO fired.

You say all this nonsense while you claim to be willing to accomodate a
client. I guess you are willing to accomodate only those client needs
that conform with your view of the world rather than the reality of the
client's data. That's the OPPOSITE of accomodation.

Your denial that you are hateful or sexist rings completely hollow.
Take your lousy attitude elsewhere and keep your dittohead politics out
of this forum.

*** Sent via Developersdex http://www.developersdex.com ***
Nov 13 '05 #14

If you are not trying to upset anyone, stop trying to upset people with
the name-calling. Completely unprofessional. Makes you look like a
real jerk.
*** Sent via Developersdex http://www.developersdex.com ***
Nov 13 '05 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Maksim | last post by:
Trying to find out a way how to restrict value of the element by name of an element, it might be not even possible, but anyhow. Let's consider following snippet: <xs:element name="tag1"...
10
by: Colleyville Alan | last post by:
I am trying to turn a short and fat (63 columns) table into one that is tall and skinny (7 columns). Basically, I am trying to create a "reverse crosstab" using a looping structure in VBA along...
2
by: LoopyNZ | last post by:
Hi, (Access 97) I'm creating a query (QRY_SUMMARY) to join a query (QRY) to itself (QRY_1). I'm returning QRY.* and selected fields from QRY_1. With each field (field_name) I return from...
11
by: MS | last post by:
The simplest input mask for peoples names is.... >L<?????????????? But what about when you have names like MacDonald, or Mary-Anne? Anyone come up with a good "all round" "idiots" mask that...
5
by: David | last post by:
Hi I seem to be getting nowhere with this. I am opening a form which will be used to input Notes into different fields in a table. My problem is changing the unbound field name to the field name...
4
by: Antonio Tirado | last post by:
Hi, I'm using the OleDB namespace to open a CSV File. I can read the file sucessfully except for hyphenated values. My CSV File contains phone numbers and sometimes these come separated with...
7
by: Mary | last post by:
I have a student who has a hyphenated first name. If I concatenate the name like this: StudentName:( & ", " & ), it works as expected. If, however, I try to get the first name first by...
5
by: rajsa | last post by:
Using a setvalue macro, I'm trying to concatenate several fields, all of which are set as 'text', but some of which contain only numbers. (Gathering data from a form into one field, then saving this...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.