RuslanAdmПеременные:
DBDATE=DMY4/
DBTIME='%y - %m - %d %H:%M:%S'
GL_DATE - не задана
Локаль ru_RU.866
Эти параметры были при выгрузке или загрузке БД ?
Или на клиенте при выполнении запросов ? Откуда вы их взяли ?
Странноватый формат разделителя для русской локали.
И в стандарте и в жизни используется . (точка).
Я не очень понял из предыдущего, при чем тут MS SQL, но загрузка данных туда без ошибок, также как и загрузка dbimport-ом, вовсе не обозначает, что данные (даты) легли именно такие, какие нужно. Например, вы могли ошибиться с форматом даты при загрузке или выгрузке (т.е. просто не указать его) и будет использоваться формат по умолчанию для этой локали (а он у вас сильно не совпадает).
Опять таки, при чем здесь 32 января ? Или это образно ? :)
Скорее всего, 29 февраля не в высокосном году, а год мог получиться неверным по простой причине загрузки двух символов года вместо четырех (получим другое столетие)...
Проверьте параметр DBCENTURY, если он установлен...
Причин может быть много.

Еще один момент.
С такой ситуацией (неверная дата в поле) я все же встречался несколько раз и причины были следующие:
- битый индекс на этой таблице (легко проверяется oncheck -cI -s)
- проблемы в приложении, которое умудрялось как то запихнуть кривые данные в таблицу во время сбоев (отрубалось насильно приложение или сервак)
Но во всех этих случаях сами данные из столбца не читались, т.е. ошибки возникали уже на этапе простого чтения таблицы. А вы говорите, что выгрузка данных таблицы проходит нормально, значит мало похоже на этот случай...

cprя бы сначала сделал oncheck -pd потом проверил индексы как указано выше
Может все таки oncheck - с d ? Тогда можно и все сразу oncheck -cDI -sqy