I also agree. Absolutely. In my organization this is a pandemic. And it strikes specially with dates. Most dates are stored as numeric(8,0) in the central DB2 database, coming directly from fields with PIC(99999999) from transactional files. In SQL Server we need them to be real dates, because the datamart needs date arithmetics (and because that is the correct way to store a date value!). So we have to explicitly make every translation and to correct the many errors we find, filtering non-valid values at ETL time. Much of this effort could be saved by just defining DATE columns in the original database. We try to evangelize on this. But, as to date, even new tables are still created with numeric(8,0) columns for date values. "For agility purposes", they say. (????)