>>
>>Do you think that using field names longer then 10 chars is wise thing to do ?
>>If so, please elaborate why.
>
>Trying to squeeze a name in 10 chars may give cryptic results/names - more difficult to remember what the field contains - more difficult to read/understand sql statements

Of course it will produce some funny field names. But we lived with it in the past already (with naming conventions/patterns etc).
Also there are field comments, captions etc for showing to user, so it is not all that bad.
(You can have lot more if you implemented some extended dictionary aside)

But those sometime cryptic sometime funny field names are IMO good trade-off versus having all other problems down the line.
Any time you pool sql query into a cursor you will get truncated field names. So any further processing by code that assumes
original field name is potential source of practical problems and/or bugs.

Sometime I wander why M$ never properly expanded DBC container into a proper table dictionary.
Instead it was left to community to make extended dictionary standards tools etc. Where all needed was few extra fields (inside DBC table)
to keep user defined properties and possibility to set/retrieve those via DBSETPROP() / DBGETPROP() . It would have been peace of cake for them to add.
Would have save people whole lot of hurdles.