>>>
>>>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.

I take it you meant 'wonder'. The why's and the If's are a thing of the past