>In my apps I assume everything up to the comma is the surname. In all cases, the users can include a comma if they so wish - if they do, my apps assume they know what they're doing. IOW, they could enter Van Hammond, John which would be left untouched. Of course, if they entered John Van Hammond it would be converted to Hammond, John Van.

Right, and the last name might be Van Hammond.

>As for Marcus Welby, MD:
>1. I do keep salutations in a separate field, if the app calls for it
>2. Can you give an example of a real person whose name REQUIRES a comma (i.e. incorrect if not present?) :-)
>
>Since my apps assume Surname, FirstName MiddleName indexing has never been a problem.

I can only say that there are potential problems.

For instance, a large amount of data has to be appended to the tables from another file (say a large new client has their data in a format that you can read and append to your data). You assumptions probably don't apply to the new data. They may have entered names with commas, or don't other "unexpected" things.

>The only real drawback to this technique would be if someone asked to search on a first or middle name, which has never been required in my apps. It still would be possible to parse out that information, just a little harder. Basically, the tradeoff is having to combine fields via views, etc. every time you want a dropdown list, report column, etc. vs. having to parse the single field in the rare cases where first or middle names are required by themselves.
>
>Another benefit not to be overlooked in high-volume apps is you can store a name, on average, with significantly fewer bytes by using a single field, than you can with separate fields.

8.4 Gb hard drive is about $175 Canadian. I agree that in some systems this may be a concern. But certainly not the majority.

>Using single or multiple fields are of course both valid approaches; I've used both over time. I just wanted to point out that for my mix of apps, the single field approach has more benefits than drawbacks. Your mileage may vary.

Exactly, for your mix of apps. Every situation is different. While you pointed out some of the benefits (of a single field), I wanted to point out a drawback or two. Not really for your benefit, because I am sure you've thought about this already, but for other people's benefit in case they "learn the hard way." They will decide what is better in their own situation.

Take care,
Joe


>
>>Just my two cents:
>>
>>By doing things this way, you lose a level of detail of data. There are also potential problems where you would confuse what is a last name and what is something else (eg. Marcus Welby, MD).
>>
>>Indexing will also not be nice in some cases. If someone enters John Van Hammond, is Van a middle name or part of the last name?
>>
>>Joe
>>
>>
>>>>How does everyone else manage the firstname and lastname fields in a database?
>>>>
>>>>Do you create a third field called name which is updated by an update trigger?
>>>>
>>>>person.lastname = "Delay"
>>>>person.firstname = "Evan"
>>>>person.name = "Delay, Evan" (trigger fills in??)
>>>>
>>>>I find that I am constantly combining the first and last name together to present to the user or for indexes..etc..
>>>>
>>>>Or do you use a function or a class...?
>>>
>>>Hi Evan,
>>>
>>>Not really an answer, but in my last few apps I've used a single field for names. I agonized over this for a while, but looking at my development history I couldn't find any cases where keeping the name broken up was of significant value. Having only one field makes a lot of these types of problems go away.
>>>
>>>In the validation code of the textbox (etc.) I put in code that basically looks for a comma. If it's there, it assumes the user knows what they're doing (e.g. De Souza, Jesus). If not, it switches words around and puts in the comma. It also doesn't attempt to "comma-ize" single names (e.g. Cher).
>>>
>>>* CHEKNAME.PRG
>>>* (c) 1998, M3 Enterprises Inc. All rights reserved.
>>>* Decides if a passed name needs to be rearranged (reversed)
>>>* using the Rev_Name() function.
>>>* This application wants names in the format
>>>* Surname, First M.
>>>* CHEKNAME returns .F. if the passed name is
>>>* not in that format.
>>>*
>>>* 98.03.25 - Al Doman
>>>* First Version
>>>* 98.03.31 - Al Doman
>>>* Changed to simply check if the passed name is OK.
>>>* Reversing function moved to Rev_Name().
>>>
>>>LPARAMETERS tcName
>>>
>>>tcName = ALLTRIM(tcName)
>>>
>>>* The name is OK if:
>>>* It is empty, or
>>>* There already is a comma in the name, or
>>>* There is NOT a space in the name. This final condition
>>>* means there is only 1 word in the name (e.g. Cher)
>>>* which is OK.
>>>
>>>* The final (no space) condition makes the EMPTY()
>>>* condition redundant:
>>>* RETURN EMPTY(tcName) OR "," $ tcName OR NOT " " $ tcName
>>>
>>>RETURN (("," $ tcName) OR (NOT " " $ tcName))
>>>
>>>
>>>* REV_NAME.PRG
>>>* (c) 1998, M3 Enterprises Inc. All rights reserved.
>>>* In a name containing 2 or more words, makes the last word
>>>* the first, following it with a comma, then appending
>>>* the other word(s) in the original order.
>>>* Used to change Alan M. Doman to Doman, Alan M.
>>>* 98.03.31 - Al Doman
>>>* First Version
>>>
>>>* NOTE this function is called only when it has been
>>>* determined already by CHEKNAME() that the name needs
>>>* to be reversed.
>>>
>>>LPARAMETERS tcName
>>>
>>>LOCAL lnLastSpace, lcSurName, lcOtherNames
>>>
>>>tcName = ALLTRIM(tcName)
>>>
>>>* If there is more than 1 word, and no comma,
>>>* we're going to assume the last word is the surname.
>>>lnLastSpace = RAT(" ", tcName)
>>>
>>>lcSurName = SUBSTR(tcName, ;
>>> lnLastSpace + 1, ;
>>> LEN(tcName) - lnLastSpace)
>>>
>>>lcOtherNames = SUBSTR(tcName, 1, lnLastSpace - 1)
>>>
>>>RETURN lcSurName + ", " + lcOtherNames