Имею MSSQL2000, w2k server использую DTS пакеты для аккумуляции данных из разных источников в MSSQL, в частности из dBase и из файлов текстового формата. Сваял эти пакет давно и около года это исправно работало. Тут на дня смотрю логи, не выполняются пакеты! Стал смотреть пакет, Не может трансформировать данные хотя ранее это делалось успешно. В частности имею такое сообщение:
TransformCopy 'DTSTransformation__1' conversion error: General conversion failure on column pair 1 (source column
'E' (DBTYPE_WSTR), destination column 'E' (DBTYPE_NUMERIC)).)
То есть имеется как бы несоответствие типов. Вопрос, отчего это могло произойти? Какие внешние причины могут так
влиять на выполнение пакета, клиентом откуда затягиваются данные является комп с win9X.
Может есть какие то соображения на этот счет?
С уважением..
Да что тут непонятного, у вас в DBF значение строкового типа невозможно перевести в число на MSSQL... Просмотрите файл, может, оператор напутал, ввел вместо числа буковки... в дальнейшем следует написать проверку типа в пакете или хотя бы конвертировать его через SQL -лексемму CASE
case <ПОЛЕ> when <условие корректной конвертации> then cast(<ПОЛЕ> as int) else 0
Всего и делов-то (с)
Кстати, та же запарка часто возникает при внесении в базу DBF-таблиц, содержащих поля даты-времени. Никто не позаботился, чтобы в DBF не было значений даты, скажем, "99/99/99"...
Здравствуйте 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"...
Здравствуйте Steppenwulf, Вы писали:
S>Да что тут непонятного,
Да, вот, проверка показала, что на источнике пользователь сменил региональные установки! Так что как бы понятно откуда ноги ростут, однако не понятно отчего даже текстовый формат не хочет кушать!
у вас в DBF значение строкового типа невозможно перевести в число на MSSQL... Просмотрите файл, может, оператор напутал, ввел вместо числа буковки... в дальнейшем следует написать проверку типа в пакете или хотя бы конвертировать его через SQL -лексемму CASE
S>S>case <ПОЛЕ> when <условие корректной конвертации> then cast(<ПОЛЕ> as int) else 0
S>
S>Всего и делов-то (с)
S>Кстати, та же запарка часто возникает при внесении в базу DBF-таблиц, содержащих поля даты-времени. Никто не позаботился, чтобы в DBF не было значений даты, скажем, "99/99/99"...
