Of course. And, there are times when it's a legacy system; or when there are special reasons (e.g., the data is going to go into a dynamic web page, and removing data conversion when inserting the numbers lessens processing resources required for 1000's of hits per second, or whatever). The point is, it happens.

>Maybe I misunderstand your point but fields containing numerics and not used in calculations should be character type, not numeric. For example, social security number, phone number, purchase order number, and the like.
>
>>You've never worked in a system where numeric entries are (sometimes) stored as character data? I wouldn't design such a system, in normal circumstances, but they do exist, and they do need conversion or fixing.
>>
>>Regarding datetimes vs dates: when I am working with the field in VFP, hitting against SQL, having the d in front tells me not to worry about the time component. Useful information.
>>
>>And, of course, finding examples where there would be no confusion is easy. But proving redundancy for easy examples does not prove the general case, which has enough exceptions to the general statement to make protecting against the exceptions a worthwhile practice.
>>
>>Hank
>>
>>>>Hi Cetin,
>>>>
>>>>prefixes tell me the type of the variable. Could it be mis-prefixed? Of course, it's dynamic type assignment in VFP. However, for all practical purposes, and that's my point, being practical, hungarian notation tells me the type of the variable.
>>>>
>>>>Hank
>>>
>>>That is a misperception. It sounds like it does but not and generally just serves as redundancy. ie:
>>>What is the prefix for Northwind Employees.BirthDate? D? On VFP yes but as soon as it is upsized it is T. Why would I think BirthDate is something other than date or datetime and prefix it? D is not helping me either. If I do it T, then it is not till upsizing. Or why would I ever prefix CompanyName? Or nAmount - is it an integer, float, double, money ...? Does it meatter? Yes it does and n doesn't tell me which one it is. If I do it i for integer and later decide to make a double would I find and replace all occurences? In real world applications database column names are not prefixed with types. That is something I hear from VFP developers only. Some weird naming conventions like customer_cCompanyName :) Redundancy. Recently I experienced it first hand that prefixing worked against me where date fields become datetime after upsizing (as I said it sticked to me as a habit, because of posting on forums, unfortunately and I use it).
>>>Cetin