My two little cents... I try to not ever use hard coded strings when accessing column names because of the problems is causes since you won't find out you have a problem until run time. If using a datatable as the datasource I get the column name from the column object. I know that wasn't the question. I just feel pain when ever I see hard coded strings.

I do appreciate both of your comments though.  They are great food for thought in other areas of my application.

Well, I am not directly binding to the table as I am using LINQ for my Queries.  Additionally, this particular field comes from a table of fields that will be constantly exapnding.  Hence, I could have 3 new fields in the table next each month or so. 

Steve,

Thanks for sharing your advice.

My own personal preference is to refer to items from our keyed collections by keys, rather than by index, whenever possible.  Depending on the collection, using the index may not be reliable.

For instance, the index of a WinGrid column in its collection is determined by the index returned from the .NET Binding Manager.  When using business objects, I've found that the binding manager sometimes gives different indexes when recompiling the business object, especially if the business object doesn't implement ITypedList.

For other keyed collections, you may be able to move a particular item within its collection.  For instance, what used to be "item 0" is now "item 2", so code that targets the item at index 0 now instead gets something different than it did before.

If you're confident that the indexes won't change and that the keys likewise won't change (such as if you have control over both the indexes and the keys assigned), then it becomes a simple matter of preference.