>Hi,
>
>Currently my application stores all preferences in several XML files. I am working on converting this approach to storing the preferences in a SQL Server table. The table name will be Preferences. In the XML files, the tag names usually correspond to the preference (for easy reading). For example, it could be 'require_labor_entry_when_closing_order'. I am thinking of replicating this XML tag names into the field/column names in the SQL Server. So the field in the SQL server table will be 'require_labor_entry_when_closing_order' type: Char(1).
>
>Is having these long field/column names in SQL Server a bad practice? TIA

Not even the small technical reason of the somewhat latedrafted addition of the vfp dbc.

But names that long will require more time just to human read/parse - even if smart editors cut down on the typing amount.
And reading will happen often, perhaps such long names will slow you - they do for my typical processing

Some of my rules of thumb are:
try to normalize AND shorten by introducing codes for often used parts (i8 for long_integer, req for require ?)
leave out parts with no real new info (perhaps "entry" in example)
if less often used, my resistance to long names is small, as impact is minimal, but if used often/regularly, I try to shorten/invent codes
keeping in line with curent naming trends I'd use perhaps "onClose"

it might be that such long names will skew your POV: this is a validation, which might be part of "onClose" but perhaps used by other
events as well - events should call methods, which are sometimes just a few calls to more atomic methods. But here perhaps my imagination is just runing wild ;-)