Здравствуйте Steppenwulf, Вы писали:

S>Да что тут непонятного, у вас в DBF значение строкового типа невозможно перевести в число на MSSQL...

Спасибо большое за реплику..

Да я вижу, что не может преобразовать. Я не могу понять причину. Дело в том, что файл DBF формируется программно, пользователь даже не знает о его существовании. И потом это происходит не только с DBF, та же картина наблюдается с TXT. То же самое можно сказать и о создании TXT файла. Его так же формирует программа. Читая БукОнЛайн нашел, что могут влиять несоответствие кодовых страниц между приемником и источником, если правильно понял, хотф, это упоминание касается только текста.

Что касается конвертации то не совсем понятен приведенный пример, я понимаю, так, что можно в DTS на каждую нить навесить ActiveX для преобразования, но это как то громоздко на мой взгляд.

Что касается кодовых страниц, то вот сейчас проверю!

А вот с датами, как Вы упоминаете далее, как то не было проблем, да и сейчас нет, при трансформации у меня две даты вставляется, но конфликтов это не вызывает.



Просмотрите файл, может, оператор напутал, ввел вместо числа буковки... в дальнейшем следует написать проверку типа в пакете или хотя бы конвертировать его через SQL -лексемму CASE

S>

S>case <ПОЛЕ> when <условие корректной конвертации> then cast(<ПОЛЕ> as int) else 0
S>

S>Всего и делов-то (с)

S>Кстати, та же запарка часто возникает при внесении в базу DBF-таблиц, содержащих поля даты-времени. Никто не позаботился, чтобы в DBF не было значений даты, скажем, "99/99/99"...