>>>As a preference... in your field names... do you include the type as part of the description...? even if you are using Hungarian notation...? such as...
>>>
>>>tstarttime vs tstart
>>>dduedate vs ddue
>>
>>My personal pref is meaningfull names or abreviations never exceeding then 10 chars in lenght.
>>
>>In this case I would simply call them
>>'StartTime'
>>'DueDate'
>>
>>But Social Security Number wld have been something like;
>>
>>SocSecNo
>>
>>When you cross 10 char limit, you are inn for all kind of surprises.
>
>What surprises have you seen? I remember Andy Neil, who I respect a lot, saying that way back in VFP 3, but ass-umed any long name issues were cleaned up by now. There is no 10 character limit documented (that I know about), which is why I ask the question.

>
>UPDATE: Well, there is the obvious limit that the DBF has to be in a DBC to use long field names. I meant other than that.

Well I keep all my tables always as part of database. I got carried away at the begining by new 'freedom' of having them more then 10 char long, but then got burned on various occasions :(

There is some commands which can create problems by being designed originally to work with free tables (DOS)

Afields() is simple example

Select MyTableWithLongFldNames
local aStru(1)
afields(aStru)

create cursor myTempCursor from array aStru

select MyTableWithLongFldNames
scan for ...

scatter memvar
.
.
insert into myTempCursor from memvar
endscan

select myTempCursor
browse normal

You will notice in copycursor that all those columns that originally had long names are being empty. No error flashed.

This with afields/create cursor is just off the top of my head. But there are more situations like this.


I simply stop using long field names. Being that DBC dictionary natively stores captions,comments etc, while extended dictionaries can store much much more data about data, I never really felt at loss because of this self imposed restriction.