This reminds me of a situation I ran into MANY times when I was writing programs for the govt. Sometimes, users would write their own apps (in Access) or contract to civilian corporations for an app to track data. Afterwards, when the reports would not print out correctly I would get called in to rewrite it (and try to pull in their data too). This happened so many times that I finally passed around a sheet to many users that told them how to determine what their reporting requirements would be now and possibly down the road to avoid this problem. Still they ignored it! Here is what they typically did on their own:

name c(50)
unit c(50)
address1 c(35)
address2 c(35)
citystzp c(50)

Then managment would want a report by last name only sometimes the names were entered first, last and sometimes last, first etc. Sometimes the rank before the name and sometimes the rank after the name. There are many grades/ranks too. Or give my a report by city and state given the data fields above (not fun). Worse, management would want a report by unit breakdown ( report grouped by unit broken down to the lowest common denominator - typically a 'rollup' report). That was impossible to do with unit field the way it was. For instance, hypothetically (and this is pretend because I could not enter real data here):

Pretend that 2nd Brigade has 9 battalions: 1,2,3 and 4... Now pretend that Each battalion has 10 companies, A,B,C, and D... Show me a roster by lastname for every brigade grouped by battalion and subgrouped by company.

Now the users would enter stuff in the unit field like:

HHC, 2nd Battalion (which brigade does it belong to?)
2BDE, HHC (Hmmmmmmm, I think HHC of 2bde,but I'm not sure)
2BD, A-3 (Doe this mean A Co, 3rd Battalion of 2nd Brigade or what?)

See what I mean. I always had to go back and fixit so it would track the information correctly which typically meant rewriting. If only they broke the information down correctly from the start.

Well, with all of this gibberish, here is my point:

The requirements are not the same for all businesses and any standards available would be obsolete as soon as they were written. A starting point is always nice though and then you can modify/adjust it to suit the business' requirements.

Tracy


>>Over the years I have encountered many "standards" for namd and address fields in other systems, and designed many of my own. The desing can vary both in terms of hoo addresses are broken into fields, and the sizes of the fields. For example, in a simple case, one could have Address1 C(30), Address2 (C30), or maybe they should be 35 characters long, or maybe 40 for long addresses. In some cases we may decide to break out the numneric portin of the street address as StreetNumber C(10), AptNummber C(10), StreetName C(30).
>>
>>Names may be broken into first and last, or first, initials, LastName.
>>
>>Emails could be c(40), or maybe this isn't long enough and we need C(70)- so what should the right length be?
>>
>>I would be interested whether there are published guidelines for this - especially in deterermining the optimum lengths so as to be able too hold typical data without making fields too long.
>
>I don't know about standards, but note that you can use a memo field to avoid wasting unneeded space. You will still have problems in reports, if you don't reserve enough space.
>
>Hilmar.