>>I support 100% long and descriptive Procedure/Class/Method/Variable names in vfp but I am
>>AGAINST using long field names in VFP. For simply practical reasons nothing else.
>>Who ever used/uses local cursors extensively, must have already or sooner/later WILL experience
>>one problem or another. As you sure know, long table names are latecomers in xbase / VFP world, so I am not sure that
>>all VFP commands/functions are 100% updated/debugged to properly process them.
>>Create Cursor / alter table alias() is one example.
>
>Create cursor is not - it's only alter table,
Yes. Create cursor / alter table is construct where I experienced problems so I have put them together in this context.

and I usually think there's something wrong with the source cursor if you need another one with a few fields less. Ulness it's something to be exported anyway, but in that case I probably need to reformat some of the fields anyway, so a custom select with sevaral ", cast(someFunc(fieldA) as C(100)) as reformattedFieldA, ..." is due anyway. I use a modified versions of intellisense script posted here (or on the wiki) by Frank Dietrich to compose a fieldlist - and then it's just a matter of deleting what I don't need and editing what I do.
>
>Most of my cursors are SPT anyway, and they come with source fieldnames as long as you like.


I am not _politically_ against long field names. Just for practical reasons :)
If you work with database that has been already created with long field names, then sure you do what you gotta do.
If I am the one that creates database then I will make sure that all field names are within 10 chars so I will have less problems down the line.
Otherwise you cope with what you have.

>
>>I had few other problems with them as well, but cannot exactly remember context.
>>However I am sure there are more. Perhaps our more experienced/knowledgeable VFP community members
>>can list out few more commands/contexts where you will run into problems with long field names.
>
>Export to fox2x tables, of course. And sometimes building a dbf with more than 200 long fieldnames may yield a Create Table command which is too long to be compiled. For a while I was maintaining a version of something like gendbc where in such cases it would dimension and populate an array of the structure required for "create table ... from array". The code was much longer than the simple "create table (...)" command, but it compiled and worked.
>
>>Do you think that using field names longer then 10 chars is wise thing to do ?
>
>Since we all pretty much use English, the language of ambiguity (or, as the moderator on xkcd forum said "no ambiguity - it has all the tools to avoid it" - ah, so it needed those tools, I wonder why), the field names need to be long enough to avoid it. Plus give it some prefixes - the xxx_field notation has saved my butt many times - you'd be left with just six characters. Now imagine you had a slightly denormalized table, with (even unprefixed) homephone1, homephone2... what do you do when you reach ten of them? And then consider the number of words which just can't be abbreviated if you want to remember what they mean in a couple of weeks. I've seen things like "del", "delete" on a boolean field - what does it mean, that it was deleted or that it can be deleted. If i's a verb, why isn't it "deleted"? Or "smthinComp" - comp as in complicated, comparative, compound, composite, complex, computer, composer, compost, compote, complete, compressed...?
>
>I remember having a field called "vrana" (srb. crow)... took me some time to remember it was "vrsta analitike" (type of analytics). Or "sumpor" (sulphur) - suma poreza (tax total).
>
>Nowadays I'm happy to be verbose. Don't have the time to write shorter (Voltaire?).

After a while I would not remember what field means even if it's names was 86 characters long! It comes with age :))
But then you open up database, you look at the code and then it all start loading itself back into the brain.

Cheers :)