SQLBulkCopy и даты (1/1/1753)

У меня есть приложение, которое отлично работает в течение довольно долгого времени, но есть раздражающий элемент, который по-прежнему мешает.

Предположим, что я использую объект, такой как OracleDataReader или MySQLDataReader, для передачи данных в объект sqlbulkcopy для вставки. Предположим, что все столбцы отображаются очень хорошо и по большей части, все работает хорошо.

Конечно, у меня нет контроля над исходным приложением или базой данных (которая является либо MySQL, либо Oracle). Таким образом, некоторые goof попадают в другое приложение и помещают дату в таблицу счетов 5/31/0210. Он действительно хотел поставить в 5/31/2010, но приложение, которое он использует, не очень точно проверяет данные, и база данных Oracle принимает его. Для всех интенсивных целей данные 5/31/0210 являются допустимой датой для Oracle db. Это может быть глупо с точки зрения ввода данных, но именно в этот момент.

Теперь наш OracleDataReader приходит и переносит эту таблицу счетов на SQL Server через SQLBulkCopy. Он передает данные в идеально подобранную таблицу с именами правых столбцов и типами данных. Вы можете видеть, что произойдет. Эта дата 05/31/0210 из Oracle не принимается движком SQL Server db, так как поле DATETIME разрешает только даты от 1/1/1753 до 12/31/9999.

Когда он сталкивается с этой записью, он просто терпит неудачу и дает ошибку переполнения. Он не пропускает запись, он убивает фид. Так что если это произойдет с тысячей записей в миллионной таблице записей, вы не получите оставшиеся 999 000 записей.

Есть ли способ обойти эту проблему, чтобы фид продолжался?

В идеале я бы хотел переместить принимающую базу данных SQL Server в 2008 и использовать DATETIME2, что позволит использовать эти тупиковые даты, но, к сожалению, не все мои клиенты готовы перейти к этой версии, поэтому я застрял с DATETIME в SQL 2000/2005/2008.

Любые идеи о том, как обойти это без изменения SQL? В идеале, я бы не прочь, если бы он просто пропустил запись. Я знаю, что я мог бы сделать это в SQL для datareder, но это было бы чрезвычайно сложно, если у вас есть двадцать полей даты в одном запросе. Это был бы кошмар.

Любые мысли были бы оценены.